What does website maintenance cost and include after launch

After launch, website maintenance is keep-the-site-alive work: hosting and DNS, dependency and CMS updates, bounded content edits, uptime watching, and backups you can actually restore. It is not new pages, new motion, or a conversion rebuild dressed up as a monthly fee. There is no honest universal monthly price — cost depends on the stack, who owns the accounts, and how often someone has to touch the site. Use labeled planning bands and a six-line checklist, not a round number you saw in a Facebook ad.

This spoke sits under Websites That Feel Like Films. The pillar is the craft standard. This is the operating bill after the premiere.

The short answer

• Care is six line items. Hosting, dependencies, CMS, content edits, uptime, backups. Anything that changes the product is a sprint.
• Platform rent is the only line with a public price tag. Webflow, Framer, Netlify, Cloudflare publish list prices. Labor does not.
• Do not mix bands. Rent, keep-alive, editorial, and new features are four different products. One invoice that says “maintenance” for all four is how buyers get burned.
• Conversion dies in the keep-alive layer. Expired SSL, a dead form, a CMS save that hides the phone number, a plugin that tanks LCP.
• If you cannot name who pays the host card in twelve months, you do not have a maintenance plan. You have a hope.

What does website maintenance include after launch?

It includes keeping the launched system running as the same film. It does not include writing a sequel.

That split is the whole post. Studios blur it because “monthly care” sounds friendlier than “we will quote the new work.” Buyers blur it because they want one number. One number that covers both is fiction.

Line item	In care (keep-alive)	Out of care (new work)	Done looks like
Hosting	Vendor plan, DNS, TLS, env vars, who pays the card	Host migration, extra environments, enterprise SLA shopping	Production URL resolves; cert is valid; billing is in your account
Dependencies	Security patches, minor upgrades, lockfile hygiene	Framework major, new animation library, stack rewrite	Known critical advisories patched; site still matches the design system
CMS	Platform updates, seats, field-level fixes, editor training	New collections, new page types, new homepage recipes	Named editor can publish without breaking type, crop, or CTA styles
Content edits	Copy and images in existing fields, within a ticket cap	New pages, new IA, new campaign landing templates	Cadence and cap written down; leftover tickets do not roll into “features”
Uptime	External check, alert path, restore-to-last-good-deploy	Perf rebuild, new CDN architecture, incident theater	Named URL, named person, named rollback
Backups	Snapshots plus a scheduled restore test	Full disaster-recovery program, multi-region redesign	Last restore date is on a calendar, not in a sales deck

If a proposal cannot fill that table, it is not a maintenance proposal. It is a retainer looking for work.

Checklist before you call anything “included”:

• Each of the six rows has an owner (you, the studio, or the vendor)
• Each row has a “not included” example in writing
• New features have a separate path (sprint, change order, or “we do not do that here”)
• Hours or tickets are capped so care cannot silently become a build
• You can leave — accounts are yours — so care is optional, not a hostage fee

Hundreds of production sites later, the sites that stay film-grade are the ones that locked this table at handoff. The sites that rot are the ones that launched and then treated the internet as a museum.

Why is there no honest universal monthly price?

Because the bill is two different species of money, and only one of them has a public sticker.

Species 1 is platform rent. Hosting, CMS site plans, extra editor seats, bandwidth overages, a domain renewal. Vendors publish those. They also change them. I will cite current public list prices below and date them. If you are reading this in 2027, open the vendor page. Do not treat this post as a price list.

Species 2 is labor. Someone has to merge the Dependabot PR, click publish, test the form on cellular, and restore a backup on purpose. Labor follows the stack, the publish cadence, and whether last month was quiet or on fire. I will not invent a studio-wide monthly retainer, a “typical client pays $X,” or a percentage-of-build rule dressed as physics.

Some agencies quote care as a percentage of the original build. That is a sales heuristic. It hides scope. A quiet Astro brochure and a Webflow CMS with weekly collections are not the same job at 15% of anything.

Why people want one number	What is actually true
“Just tell me the monthly”	Rent is knowable. Labor is a band that moves with tickets.
“My cousin’s site is $50/mo”	That is often hosting plus hope. Hope is not a restore strategy.
“Care should be a round hundred”	Round numbers are branding. Scope is the product.
“If I pay monthly I should get new pages”	Then you bought a tiny agency, not maintenance. Price it as such.
“Custom should include forever updates”	Custom buys a system. Forever updates are a second contract.

Procedure for a number you can defend in a budget meeting:

1. Sum current vendor list prices for hosting, CMS, seats, and the domain.
2. Count last quarter’s real tickets: patches, copy edits, incidents.
3. Assign those tickets to keep-alive vs editorial vs product. Be cruel about the third bucket.
4. Size labor as hours for buckets one and two only. Apply that studio’s rate, not a blog’s.
5. Quote product work as a sprint. Do not average it into the month so it looks cheap.

If step 4 is zero hours because “the client will do it,” say that out loud. Unpriced self-serve is still cost. It just lands on the owner’s Tuesday night.

What do platform list prices actually cover?

They cover the rented runtime. They do not cover a human.

Read the vendor page the week you budget. As of August 2026, public US list prices for stacks I actually ship look like this. Taxes, domains, apps, overages, and workspace seats sit on top.

Stack	What you are paying	Public shape (verify before you budget)
Webflow Site plan	Hosted site + CMS (on Premium)	Webflow pricing: Basic $15/mo billed yearly; Premium $25/mo billed yearly. Webflow’s May 2026 plan note also lists monthly billing at $25 (Basic) and $39 (Premium).
Webflow Workspace	Staging, seats, export — on top of the Site plan	Same pricing page: Starter Workspace is free; Core $19/mo billed yearly; Growth $49/mo billed yearly. Headline Site price is not the whole bill.
Framer site plan	Hosted Framer site + CMS limits	Framer pricing (yearly view when I checked): Basic $10/mo, Pro $30/mo. Extra editors $20/mo; content editors $10/mo. Monthly vs yearly is chosen at checkout.
Netlify	Builds, CDN, functions, credits	Netlify pricing / credit-plan docs: Free $0 (300 credits, hard limit); Personal $9/mo (1,000 credits); Pro starts at $20/mo (3,000 credits). New accounts moved to credits on 4 Sep 2025; older accounts may still be on legacy plans.
Cloudflare Workers / Pages	Functions + static	Workers pricing: Workers Paid is a $5/month minimum, with included request and CPU allotments and overage rates. Static asset requests on Pages are documented as free.
Domain	Registrar renewal	Separate from hosting. Check the registrar you actually use. Do not assume a “free first year” lasts.

What that rent includes, when it is doing its job:

1. HTTPS and a CDN (or equivalent edge)
2. The vendor’s editor or deploy pipeline
3. Plan-level backups / deploy history — vendor-shaped, not a 3-2-1 program
4. Support at that plan’s level, which is often “search the forum”

What it does not include:

1. Someone watching whether the form still hits a human inbox
2. Merging security updates
3. Writing this month’s tour dates
4. A contractual uptime SLA on cheap tiers

Netlify’s own pricing page attaches a 99.99% SLA to Enterprise, not to Free / Personal / Pro. Netlify for enterprises repeats the 99.99% uptime SLA on the enterprise network. If your “maintenance” pitch implied a financial SLA on a $20 Pro plan, it implied a product the vendor does not sell at that tier.

• Site plan and workspace / seat plan are both in the budget (Webflow especially)
• Billing is on a card the client controls
• You know whether you are on Netlify credits or a legacy plan
• Bandwidth / credit overages have an alert, not a surprise invoice
• Domain auto-renew is on, on an inbox someone reads

Platform rent is the floor. Treat it as the floor.

What do dependency and CMS updates actually mean?

They mean the site keeps the same behavior while the ground under it moves.

On a custom or Astro / Git-hosted site, dependencies are npm (or equivalent) packages, GitHub Actions, and any edge functions. Dependabot security updates open pull requests when GitHub raises an alert. They do not merge themselves. An unmerged PR is not a patch. It is a notification you ignored.

On Webflow or Framer, you are on the vendor’s runtime. You still have: editor seats, CMS item limits, third-party embeds, form endpoints, and the occasional platform change that moves a class or a field. “No package.json” is not “no upkeep.” It is a different upkeep.

Work	Custom / Git site	Webflow / Framer site
Security patch	Review and merge Dependabot (or equivalent), deploy, click the conversion path	Apply vendor platform updates; re-test forms, CMS, and the fold
Minor upgrade	Intentional; staging first	Usually vendor-side; still QA the published site
Major upgrade	A project. Quote it.	Collection remodel, new hosting tier, or localization add-on — also a project
Plugin / embed	Lockfile + license renewal	Script in head/footer; treat it like a dependency
CMS schema	Code + content model	Collections and field limits; Premium vs Basic is a product choice

Procedure I actually use on Git-hosted marketing sites:

1. Turn on dependency graph, Dependabot alerts, and security updates on the production repo.
2. Group noisy patches so you are not merging theater. Security still ships first.
3. Deploy to a preview URL. Walk the fold, the form, and one interior page on a phone.
4. Promote to production. Confirm analytics still fire.
5. If a major lands (framework, Node, a motion library), stop calling it maintenance. Open a change order.

Failure mode, named: Dependabot opened fourteen PRs. Nobody merged them because “the site looks fine.” Six months later a transitive package is the incident. Looking fine was never the test. The test is whether you can still ship a patch without a scavenger hunt.

• Alerts go to an inbox a human reads, not a dead GitHub notification badge
• Preview deploys exist (Netlify / Framer Pro staging / Webflow staging on a paid Workspace)
• License renewals for paid plugins are on a calendar
• “We’ll update it when it breaks” is not the written policy

A PR is not a patch until production still converts.

Which content edits belong in care versus a sprint?

Edits that fill existing fields belong in care. Edits that change the system belong in a sprint.

That is the same CMS honesty as the pillar: give editors copy, images, and posts — not a page builder that can become a different brand in one afternoon. Care should make that model cheaper to run, not punch holes in it.

Ticket	Care	Sprint
Swap a headline in the existing H1 field	Yes	No
Replace a project still at the locked ratio	Yes	No
Add a tour date to the dates collection	Yes	No
Rewrite the homepage job of the fold	No	Yes
Add a seventh section recipe	No	Yes
New landing page from an existing recipe	Maybe, if the recipe is already a duplicate-and-fill	Yes, if it needs new composition
New CMS collection	No	Yes
Motion pass, new hero, WebGL	No	Yes

Artist sites live or die on this split. A date change in the tour collection is care. A new listen-first fold is the conversion work in Artist website conversion — that is product. If your “maintenance” includes a new title card every quarter, you did not buy care. You bought a standing redesign with worse accounting.

Trades sites are the same rule with a louder phone. Updating a service-area sentence is care. Rebuilding the tap-to-call fold is a sprint. See Trades and SMB website playbook.

Bounded editorial, written so it cannot sprawl:

1. Name the fields editors may change. Screenshot them.
2. Cap tickets or hours per month. Unused cap does not convert into “bonus features.”
3. Anything that needs a new composition goes to a backlog, not into this month’s care.
4. Publish from staging when the stack has it. The homepage is not a scratchpad.
5. After publish: one phone pass on the primary CTA.

• Field list exists (headline, body, image, dates, not “the page”)
• Monthly cap exists as a number, not a vibe
• Overflow is a change order, not a grudge
• Alt text is required on image fields — not a later chore

If the brand can be broken in one afternoon of “just updating the hero,” care is how you pay someone to break it on a schedule. Lock the grade. Then edit inside the locks.

How should uptime and backups be scoped?

Uptime is “we notice and roll back.” Backups are “we can restore.” Neither is a vibe. Neither is the vendor’s marketing uptime on a plan with no SLA.

Cheap tiers are usually fast. They are not a contract. If you need a financial SLA, you are shopping Enterprise (Netlify’s public 99.99% SLA is an Enterprise line, not Pro). Most brand sites do not need that contract. They need a check, an alert, and a last-good deploy.

CISA’s small-business backup page is blunt: inventory what you cannot lose, then follow 3-2-1 — three copies, two media types, one off-site — and test restores (CISA: Back Up Business Data). CISA’s data backup options brief is the same 3-2-1 in one page. A host’s deploy history is one copy. It is not a program.

Control	Minimum care	Not care (bigger project)
Uptime	External HTTP(S) check on the production URL; alert to a human	Multi-region active-active, paid SLA, war-room retainers
Incident	Restore last good deploy / DNS TTL you actually set	Rewrite the app while the site is down
Backup	CMS export or Git + host snapshots + one off-site export	Enterprise backup product, legal hold, multi-year archives
Restore test	Calendar item: restore to staging, click the form	Tabletop theater with no restore
Secrets	Env vars in the host, not in a chat log	Full secrets-management platform

Procedure — restore test that counts:

1. Pick a date. Put it on a shared calendar. Quarterly is a sane default for a marketing site; more often if the CMS is the business.
2. Restore to a non-production URL (Netlify deploy, Framer staging, Webflow staging site).
3. Confirm the fold, a CMS item, and the form endpoint. Not “the ZIP downloaded.”
4. Write the last-success date where the next person can find it.
5. If restore fails, that ticket is care. Fix the backup. Do not wait for a real incident.

• Monitor hits the custom domain, not only the *.webflow.io / *.netlify.app preview
• Alert is not a Slack channel nobody joined
• Rollback owner is named (and has access)
• CMS content is in the backup, not only the repo of a static shell
• Form provider is in the inventory — a restored page with a dead form is still an outage

An untested backup is a story you tell yourself. Bravery is not a restore strategy.

How do you pick a planning band without a rate card?

You label the work, then you size hours. You do not start with a monthly you saw on Twitter.

I will not publish Spurlock Studios retainers here. I will not invent “most clients pay.” These are planning bands — names for a budget conversation. The dollars are vendor stickers plus whatever the studio in front of you charges for the hours in that band.

Band	Includes	Does not include	How to size it
A — Platform rent	Vendor invoices only. Client or studio pays them; nobody is on retainer.	Any human work	Sum the list-price table. Re-check yearly.
B — Keep-alive	Rent + deps/CMS patches + uptime check + backup restore test	Editorial, new pages, design	Hours for a quiet month vs a patchy month. Quiet can be a handful. A major is a project.
C — Care + editorial	Band B + bounded field edits at a ticket or hour cap	New recipes, motion, IA, conversion experiments	Hours × how often the CMS must move (weekly dates vs twice a year)
D — Product / sprint	Scoped new work: fold, pages, motion, CMS model, migration	Mixing this into “the monthly” so it looks cheaper	Quote as a sprint. See /websites.

Decision list — pick one band and write it on the SOW:

• Band A if the owner is technical, tickets are rare, and you accept that nothing happens unless they open the CMS
• Band B if the stack has a lockfile or a vendor runtime you refuse to ignore
• Band C if a human must publish on a cadence (tour, menu, service-area, season)
• Band D if the fold, IA, or stack is the actual problem — stop buying care for a site that needs a sprint

Worked examples, hours as the unit, still not a rate card:

• Static custom site, owner never edits. Band B. Rent might be Netlify Personal at $9 or Cloudflare Workers Paid at $5, plus a domain. Labor is patch-and-watch. If nothing ships for a month, the honest hour count is small. Budget a spike for a real advisory.
• Framer or Webflow with weekly CMS. Band C. Rent is Site plan plus seats (Framer extra editors at $20/mo; Webflow Workspace if you need staging/export). Labor follows the calendar of dates and stills, not the calendar of invoices.
• “We also want a new homepage in Q4.” Band C for the year plus a Band D sprint. Do not average the homepage into twelve fake months.

If two studios quote different months, force both onto this table. The cheaper one is often Band A with a smile.

What usually fails first after a film-grade launch?

The host card, the unmerged patch, or the promise that “care includes whatever you need.”

Those three take a site that felt expensive on launch day and make it feel abandoned. Conversion follows. A trades caller who hits a dead form does not wait for your sprint retrospective. An artist with last year’s tour dates in the CMS is telling bookers the project is over.

Failure	What it costs	What you do instead
Host / registrar card expires	Site offline; email and DNS can go with it	Client-owned billing; calendar 30 days before expiry
SSL not renewing	Browsers block the fold. Trust is gone.	Auto-renew on a host you control; monitor the custom domain
Form endpoint dies (Zap, inbox, SaaS plan)	Leads to /dev/null	Monthly submit-from-phone test; inbox in the client’s domain
Dependabot pile	Incident later, under time pressure	Weekly merge window; majors as change orders
CMS fat-finger on the fold	Brand looks accidental; CTA missing on mobile	Locked fields; preview; named publisher
“Unlimited edits” retainer	Studio goes quiet or quality tanks	Caps. Overflow is a quote.
Backup never restored	You learn at the worst time	Quarterly restore to staging
Care billed, features delivered	Scope fight; the film drifts	Six-line table in the SOW

The conversion angle is not mystical. Maintenance protects the path you already paid to design. If the fold, the tap-to-call, or the listen button breaks, you did not “lose a little SEO.” You closed the store at random hours.

Procedure when something already feels off:

1. Hit the production URL on cellular. Complete the primary action.
2. Check registrar and host billing dates.
3. Submit the form from a second device. Confirm the inbox.
4. List open security PRs older than seven days.
5. Check last restore-test date.
6. Only then talk about new pages.

If steps 1–5 fail, do not buy a motion pass. You do not have a cinema problem. You have a keep-alive problem.

How do artist versus trades sites change the care mix?

Same six line items. Different cadence. Different death state.

The pillar already splits conversion mechanics: artists need identity then listen/tour/contact; trades need trust and the phone. Care is those mechanics on a calendar.

	Artist / musician site	Trades / local SMB
Hosting	Same rule: client-owned billing	Same, plus you cannot afford a weekend outage during storm season
Deps / CMS	Tour collection, listen links, merch URLs rot fast	Service pages rot slower; NAP and tel: links must not drift
Content edits	Dates, releases, press stills — often weekly in season	Hours, service area, seasonal copy — often monthly
Uptime	Show week is not the week to discover DNS is on a dead card	Missed calls are the product leaking
Backups	CMS items are the site	Reviews and service copy still need an export
Band I default toward	C in season, B in the off months if dates freeze	B or light C; D if the phone path was never built

I will not invent retainers for Arkayla, Foxtide, Matt Coffey, AllCity HVAC, or Divine Toke. Portfolio names prove the kinds of sites. They are not a license to fabricate monthly fees.

Decision checklist by lane:

• Artist: tour/listen URLs are CMS fields, not hardcoded in a hero the owner cannot touch
• Artist: a date change does not require a designer
• Trades: tap-to-call is tested after every publish
• Trades: NAP is consistent; hours live in one field, not five pages
• Both: primary CTA still works if motion is off

If you are still arguing about grain overlays while the phone number is a screenshot, you are maintaining the wrong layer.

What should you ask a designer before you sign care?

Ask them to fill the six-line table, name the band, and show you the accounts.

If they cannot, you are buying access to a person, not an operating plan — and paying monthly to stay stuck.

Question	Acceptable answer	Walk-away answer
What is included?	The six rows, with outs	“Whatever you need,” “unlimited”
What band is this?	A / B / C, plus D as change orders	One blended number with no hours
Who pays hosting?	You, on your card	“It’s easier if we bill it” with no transfer plan
What is the ticket cap?	A number per month	“We just handle it”
How do we request a new page?	Sprint / change order	“That’s included”
When did you last restore a backup?	A date	“The host does that”
What happens if we pause?	Site keeps running; they lose access	Hosting dies because it was on their card
Who is on-call for an outage?	Named human + hours	An Instagram DM

Procedure for the sales call:

1. Send the six-line table ahead of the call. Ask them to fill it.
2. Ask which vendor plans they assumed. Compare to the pricing pages above.
3. Ask for the hour assumption in Band B vs C. If they will not talk hours, they are hiding a blended D.
4. Confirm registrar, host, CMS, analytics are already in your logins — or that transfer is week one of care, not a favor later.
5. Write the cap and the overflow path in the SOW. Not in a Slack sidebar.

• SOW lists hosting as pass-through or client-paid, not a mystery markup with no line
• Security patches have a cadence
• Editorial has a cadence and a cap
• Product work is explicitly excluded
• Exit does not take the site down

A designer who built a film-grade site can still be a bad care vendor. Building and keeping-alive are different jobs. Hire for the job you are buying.

When is a custom site worth maintaining versus rebuilding?

Maintain when the system is still the system. Rebuild when care would be paying rent on a leak.

Custom is worth the keep-alive bill when you already bought authorship — compositions, a locked type system, a CMS the real editor will open — and the failure is time, not structure. That is the “worth it” test from this pillar’s cluster, applied after launch rather than before.

Signal	Maintain (B or C)	Sprint (D)	Rebuild
Fold still has one job; CMS still matches the rhythm	Yes	No	No
Fold is the leak; IA is fine	No	Yes	No
Motion / LCP regressed after a plugin	Maybe a keep-alive patch	Yes if the stack cannot host a budget	Only if the platform is the ceiling
Editors broke the grade because fields were too free	Tighten fields in care	Redesign recipes	If every page is a unique accident
You cannot leave the platform	Pause care; fix ownership first	—	Then decide
Theme owns every composition	You are maintaining a costume	Heavy sprint maybe	Often a rebuild
No conversion path exists	Care will polish a closed store	Build the path	If IA is a junk drawer

Decision procedure:

1. Walk the site on a mid-range phone. Name the failure: fold, path, proof, stack, or keep-alive.
2. If keep-alive (SSL, form, dates, billing), buy Band B/C. Do not rebuild.
3. If fold/path/proof, buy a sprint. Do not hide it in a retainer.
4. If IA or platform is the product, rebuild. Care on a rotten IA trains you to add more rot.
5. If ownership fails, stop. Accounts first. Care second.

A custom site is worth maintaining when the authored system is still cheaper than starting over. It is not worth a monthly if nobody can edit it, nobody owns the card, and the fold never had a job. In that case the honest product is a sprint or a rebuild — named, scoped, and not called maintenance.

How do you measure whether care is working?

You measure whether the launched path still completes, and whether the keep-alive calendar is real.

Not “we sent invoices.” Not “the site looks pretty in Dribbble crops.” Care is working if a stranger can still do the one job of the site, patches are not aging into incidents, and you can restore.

Signal	Healthy	Sick
Primary action on cellular	Completes this month	Last tested at launch
Form / tap-to-call / listen	Inbox or app received it	Nobody knows
Security PRs	Merged inside an agreed window	Pile older than a month
Restore test	Date on a calendar this quarter	“The host has backups”
Ticket log	Keep-alive vs editorial vs product tagged	Everything is “the monthly”
Host invoice	Matches the plan you chose	Mystery overages
Visual grade	Editors stayed inside fields	Homepage is a collage of exceptions
Time-to-rollback	Named and drilled	Heroics

Monthly measurement procedure (thirty minutes, not a workshop):

1. Phone: land, say the offer, complete the CTA.
2. Submit the form or tap the call link. Confirm the destination.
3. Open the host bill. Match it to the plan.
4. Count open dependency alerts.
5. Confirm last restore-test date.
6. Tag last month’s tickets into A/B/C/D. If D tickets hid in C, the band is lying.

Conversion is downstream of that list. You cannot A/B a headline if the form posts nowhere. You cannot “do SEO” on a domain whose TLS is scary. Measure keep-alive first. Then argue about copy.

• A shared doc has last-test dates (form, restore, phone walk)
• One person is accountable. “The team” is nobody
• Product requests have their own column so care metrics stay clean

If you only have a week and the site is already live, you are not picking a brand color. You are proving the store still opens.

What should you skip if you only have a week?

Skip new pages, new motion, and a CMS remodel. Do the keep-alive proof.

A week is enough to find out whether you need Band B, Band C, or a sprint. It is not enough to fake a year of care.

Do this week	Skip this week
Inventory: registrar, host, CMS, repo, analytics, form provider, who pays	New homepage
Put billing on a card you control	“Unlimited edits” negotiation
External uptime check on the custom domain	Enterprise SLA shopping
Form test from a phone	New lead-magnet funnel
Merge or schedule critical security updates	Framework major
One restore to staging	Multi-region architecture
Write the six-line table and pick a band	A round monthly you cannot defend
Lock CMS fields if editors can wreck the fold	A new design system

One-week procedure:

1. Day 1 — Accounts. Logins in a password manager the company owns. Host and registrar billing in the company’s name.
2. Day 2 — Path. Cellular walk. Form or tap-to-call confirmed. Fix that before anything pretty.
3. Day 3 — Runtime. Which vendor plan are you actually on? Match the invoice to the pricing page.
4. Day 4 — Patches. Open alerts. Merge what is safe. Park majors.
5. Day 5 — Restore. Staging restore. Write the date.
6. Day 6 — Scope. Fill the six-line table. Assign A/B/C/D.
7. Day 7 — Decision. Sign a care SOW that matches the band, or book a sprint, or stop paying a blended fiction.

When this is not worth doing yet: the site is not launched; you do not own the accounts and the builder will not transfer them; you already know you are throwing the stack away next month; there is no conversion path, so you would be maintaining a brochure. In those cases, fix ownership or buy the sprint. Do not hire a janitor for a building you are about to demolish.

FAQ

What does website maintenance cost and include after launch?

It includes hosting, dependency and CMS updates, bounded content edits, uptime watching, and backups you can restore — not new features. Cost is platform list prices plus labor, and labor depends on stack and cadence, so there is no honest universal monthly. Use labeled bands (rent, keep-alive, care plus editorial, product) and price hours with the studio in front of you.

How do I measure whether website maintenance is working after launch?

Measure whether the primary action still completes on a phone, whether forms or tap-to-call still hit a human, whether security patches are merging, and whether a restore has been tested this quarter. Invoices are not a metric. A tagged ticket log that separates keep-alive, editorial, and product work is.

What usually fails first when teams try this?

Billing on someone else’s card, unmerged security updates, and a “care” SOW that secretly includes new pages. After that: dead form endpoints and CMS edits that break the fold. Fix those before you buy another motion pass.

How long does this take to show results?

Keep-alive shows up the first time something would have gone down and did not — often a form test, a patched advisory, or a card that did not expire. Editorial care shows up on the next real publish (a date, a still, a service-area line). Product work is a sprint timeline, not a maintenance timeline. Do not wait a quarter to find out the backup never restored.

What should I skip if I only have a week?

Skip new pages and redesign. Inventory accounts, move billing, test the conversion path, turn on an uptime check, deal with critical patches, and run one restore to staging. End the week with the six-line table and a band. That is a real plan. A fake monthly is not.

When is this not worth doing yet?

When the site is not live, when you do not own registrar and hosting, when you are about to rebuild the stack, or when there is no conversion path to protect. Care cannot replace a missing fold job. Buy a sprint or finish launch first.

CTA

If the premiere already shipped, stop paying for mystery months. Name the six line items, pick a band, and keep the film on the screen.

Explore /websites or book a Website sprint at /contact?intent=websites-sprint.