Workflow capability
A defined customer or operator sequence
Add one missing commerce action with named inputs, outputs, permissions, states and failure handling.
One job · one outcomeOpen route →Loading content
Custom development / WooCommerce
This P2 path is for one missing ecommerce capability when native behaviour and maintained software do not fit. It is not a route for repairing an existing plugin, diagnosing a store fault, improving performance or providing ongoing maintenance.
A bounded addon starts with acceptance criteria and ends with code, testing evidence and a clear handover.
Qualifying boundaries
01One primary outcome02Named users and surfaces03Scoped versions and dependencies04Observable acceptance scenariosDiscovery
Workflow capability
Add one missing commerce action with named inputs, outputs, permissions, states and failure handling.
One job · one outcomeOpen route →Checkout or order capability
Define the affected checkout or order surfaces, customer states, administrator actions and acceptance evidence.
Scope includes affected versions and dependenciesOpen route →Admin or regulatory capability
Translate an approved operational requirement into fields, screens, actions, records and measurable outcomes.
Legal applicability remains outside the software claimOpen route →Bounded integration
Specify events, payloads, authentication ownership, limits, failure handling and reconciliation without exposing secrets.
Contract · failure · recoveryOpen route →Technical scope
The brief records WooCommerce, WordPress and PHP versions, theme or checkout dependencies, affected objects, permissions, personal-data categories, external calls and install, update and uninstall behaviour.
Compatibility is limited to the agreed and tested scope. Future versions, later third-party changes and indefinite updates are separate decisions.
Acceptance
Acceptance uses observable scenarios for the named job, expected permissions, important failures, recovery and the agreed compatibility surface.
Passwords, API secrets, production exports and unnecessary personal data do not belong in the public brief.
Decision path
Confirm that the request is one new bounded capability and not repair or broad store work.
Agree actors, workflow, versions, dependencies, data, failure states and acceptance.
A scoped quote precedes implementation; testing follows the approved scenarios.
Correct in-scope defects, then deliver the paid package, evidence and contracted source.
Qualification
A workflow, checkout or order capability, admin tool, regulatory function, bounded integration or other missing ecommerce job.
A broken plugin, store error, compatibility audit, background-job recovery, performance work, migration, maintenance or theme bug.
Use maintained native capability or an established extension when it meets the requirement and ownership needs.
Describe systems and data classes without passwords, tokens, production exports or unnecessary personal data.
Requirements brief
Business outcome, named users, current process, desired state, trigger, inputs and outputs.
WooCommerce, WordPress and PHP versions, theme or checkout dependencies, UI surfaces, events, integrations, notifications and files.
Data handled, privacy needs, permissions, volumes, failure and recovery states, and third-party limits.
Observable scenarios, in/out of scope, operational owner, deadline driver and technical contact.
Commercial boundary
The agreed package may include version/hash, compatibility scope, scenario results, screenshots, known limits, data map, documentation and uninstall behaviour.
The approved specification sets the criteria. Reproducible defects against those criteria are corrected during acceptance.
Covers reproducible bugs attributable to the delivered development; not new features, later requirements, third-party changes or future out-of-scope incompatibility.
Contracted source is delivered after full payment. PsDevs retains pre-existing tooling, libraries, reusable generic components and know-how; exclusivity is separate.