WordPress development and WordPress maintenance are different operating services. Development changes what the site is or does. Maintenance keeps the agreed site secure, updated, recoverable, and operational within a recurring support scope.
The distinction matters because agencies often sell “maintenance” and then discover that clients expect unlimited new development.
AxiomLift separates white label WordPress development from white label WordPress maintenance because the project and recurring-support buyer jobs are different.
The short comparison
| Work type | Development | Maintenance |
|---|---|---|
| New website build | Yes | No |
| Major redesign | Yes | No |
| New template/component | Usually | Only if explicitly included |
| New integration | Usually | Not routine maintenance |
| Core/plugin/theme updates | Can occur during build | Common recurring work |
| Backups | Launch requirement | Common recurring work |
| Monitoring | Project-specific | Common recurring work |
| Incident support | During warranty/project scope | Defined by SLA |
| Small content changes | Can be part of build | May be included within limits |
| New custom feature | Yes | Separate scope in most plans |
The exact contract can vary, but the agency should choose and communicate a boundary.
Development is a change project
Development usually includes work such as:
- new site builds
- redesigns
- migrations
- custom theme/block/component work
- WooCommerce or ecommerce features where scoped
- new integrations
- custom post types/data models
- major performance refactors
- new user flows
It has a beginning, defined acceptance criteria, and a handoff.
The Figma-to-WordPress checklist shows how design-led projects can be handed to development cleanly.
Maintenance is an operating service
Maintenance commonly includes recurring tasks such as:
- software updates
- backups
- monitoring
- compatibility checks
- incident triage
- minor content/configuration changes within limits
- security-related maintenance within scope
- reporting
The key word is recurring. The provider is maintaining an agreed system rather than continuously redesigning it.
The gray area: small changes
Clients often ask, “Can you just add this?”
Create a small-change rule before the contract begins.
A possible classification:
Maintenance change
Uses an existing component or setting and does not alter the site’s underlying design/function model.
Examples:
- replace existing text/image
- update a link
- adjust a configured setting
- add a page using an existing template
Development change
Requires new behavior, architecture, code, design, or integration.
Examples:
- new custom calculator
- new checkout logic
- new membership feature
- custom CRM integration
- new page template
- redesign of global navigation
The boundary can depend on the site, but it should be explainable.
Separate bug fixes from new requirements
A bug means agreed functionality is not working as intended. A new requirement changes what “intended” means.
Write acceptance criteria during development so this distinction can be made later.
For example:
Bug: the approved mobile menu does not open at a supported viewport.
New requirement: the client decides after launch that the mobile menu should use an entirely different navigation structure.
Both require work, but they belong in different commercial categories.
Use a post-launch transition
A clean website project should explicitly transition from development into maintenance.
At handoff, record:
- production state
- repository
- hosting/DNS
- admin access
- licenses
- backups
- known issues
- maintenance start date
- support channel
- SLA/severity rules
The website handoff checklist provides the full closeout inventory.
Maintenance needs an SLA; development needs acceptance criteria
These services use different control systems.
Development controls
- scope
- milestones
- design approval
- acceptance criteria
- change requests
- launch checklist
Maintenance controls
- support hours
- severity definitions
- response expectations
- backup/update policy
- incident workflow
- exclusions
Use the WordPress maintenance SLA checklist for the recurring side.
Why agencies should price them separately
Development effort is often project-specific. Maintenance is recurring and depends on the site, stack, support expectations, and risk profile.
Combining them into one vague monthly promise can create two problems:
- Development requests consume all maintenance capacity.
- The agency cannot tell whether the recurring plan is profitable.
A clearer model can offer maintenance with a defined small-change allowance and quote larger development work separately.
Decision rule for a new request
Ask these questions:
- Does the request use existing functionality or create new functionality?
- Does it change approved design/architecture?
- Does it require new integration or custom code?
- Can it be completed safely inside the maintenance change allowance?
- Does it introduce a new long-term maintenance obligation?
- Does it require separate QA/acceptance?
If several answers point to new scope, treat it as development.
The practical boundary
Maintenance protects continuity. Development creates change.
Agencies can sell both, but clients and fulfillment teams should know which commercial process a request enters before the work begins.