Requirements and existing code review
Define development boundaries by reviewing expected behaviour and the responsibilities of the current theme and plugins.
WordPress services
Develop new capabilities with the existing theme and plugin architecture in mind.

The written scope defines actions and access within the selected product limits.
Define development boundaries by reviewing expected behaviour and the responsibilities of the current theme and plugins.
Specify theme, plugin or API work through written acceptance criteria, separating external access requirements and service fees.
Check functionality against agreed versions and user flows; identify combinations that have not been tested.
A conceptual example explaining the approach, not a customer project or an achieved result.
An example website needs its existing form to collect different information; the purpose and fields are defined.
Theme changes, plugin extensions and API connections are assessed against the available access and existing setup.
The selected solution is reviewed using agreed scenarios; publication and subsequent maintenance are decided separately.
An illustrative workflow, not a customer project.
Timing, authorised access and responsibilities are agreed with the scope.
Review authorised access, versions and current behaviour, identifying the responsible people.
Planned outputCurrent state and access record
Record package boundaries, test workflows and recovery requirements.
Planned outputWritten scope and verification plan
Apply approved changes in a suitable environment, recording unverified dependencies.
Planned outputRecord of applied changes
Share check results, outstanding needs and subsequent maintenance responsibilities.
Planned outputCheck results and next steps
The product and written scope define final deliverables; not every item is included in every package.
Licences, further development and ongoing support are defined separately. A backup does not prove successful restoration.
Compatibility covers the reviewed installation and agreed versions, not every unknown component or future update.
Authorised access, documentation, usage limits and any test account are needed. Third-party fees and approvals remain separate.
Use of a suitable test environment is agreed first. Live changes require approval; environment preparation may need additional scope.
Deliverable files, rights and access follow the agreement. Ownership of third-party components is not automatically transferred.
Development delivery does not imply ongoing compatibility maintenance. Later updates and support periods are agreed separately.
Current prices come from the catalogue below. Compare features and scope; this explanation adds neither unlimited interventions nor a fixed delivery deadline.
WordPress Development
Ten hours of WordPress development for the approved task list.
Estimated delivery: 5–15 business days after scheduling
Excluded: Time carried over after sixty days
Excluded: Third-party licences
Excluded: Redesign outside the scope
Excluding VAT