# How to Structure a Dedicated PHP Development Retainer > Structure recurring PHP development around capacity, backlog ownership, maintenance boundaries, release controls and visible decisions. Canonical page: https://webvelopment.co.za/insights/development/dedicated-php-development-retainer/ Language: en Development insights A PHP development retainer needs a maintained backlog, a decision owner and a release process as well as an allocation of hours. Start with the application you actually operate and define how support, improvement work and unexpected incidents use the agreed capacity. Webvelopment · 25 October 2026 ## Decide what the retainer reserves A PHP development retainer should help you decide what gets attention next, without renegotiating the whole relationship for each request. You might need reserved development capacity, a defined maintenance service, or planned improvements alongside operational care. We would start by naming that need. “Ongoing support” leaves too much unanswered: does it cover a broken integration, a feature request, or responsibility for noticing a failure in the first place? Bring an outline of the application, where it is hosted, its framework or custom architecture, and the services it connects to. Include who can grant access to each part. If the current condition is unclear, an initial audit may be needed before we can estimate changes or take on operational responsibilities. Name that onboarding work in the agreement so both sides understand what the first period needs to establish. ## Define the backlog and decision owner Keep requests in one prioritised backlog and nominate someone on your side who can choose between competing needs. For each item, explain what happens now, what should happen instead, and how you will check the change. A screenshot or reproducible sequence is more useful than a ticket that only says “fix the form”. When the cause is unknown, give investigation its own place in the queue and define the question it needs to answer. Agree how urgent requests change that queue. When a production problem takes priority, name the planned work it displaces and let the client decision-maker confirm the trade-off. Keep both items visible. That gives you an honest explanation of what moved, instead of a month-end surprise after priorities changed in private messages. ## Separate the work categories Use these categories to make requests easier to discuss. The distinction matters when the same symptom could mean restoring agreed behaviour or asking for something new. | Work type | Typical purpose | Agreement needed | | --- | --- | --- | | Maintenance | Keep the agreed system serviceable | Supported components and exclusions | | Defect correction | Restore agreed behaviour | Reproduction and acceptance baseline | | Improvement | Change or extend behaviour | Scope, priority and review | | Investigation | Reduce uncertainty | Question, time boundary and findings | | Incident response | Handle an operational interruption | Contact route and actual coverage | These categories do not establish a service-level promise. Response times, out-of-hours availability and emergency arrangements must be negotiated against real staffing and infrastructure. ## Make releases a first-class responsibility Agree where development and staging happen, who approves production changes and how deployment is performed. For each meaningful release, explain the backup, database migration and rollback considerations. Your reviewer needs to know where to try the change and what to check; the person deploying it needs to know what steps remain. Code on a developer’s machine is only part of that work. Keep access proportionate to responsibility. A developer who changes application code does not automatically need unrestricted control of billing, domains or every production service. Use individual access where possible and maintain a process for changing or removing it when responsibilities change. ## Report progress without creating theatre A useful review lets you answer four questions: what can we now use, what changed in the plan, what is still unknown, and what do you need to decide? Hours can support commercial reporting, but they cannot answer those questions alone. Link each completed item to the change you can inspect, the checks performed or the investigation findings. Track recurring interruptions alongside planned work. If the same integration keeps failing, bring those incidents together at review so you can decide whether to investigate the underlying problem. Otherwise, separate tickets can hide how much attention one part of the application is taking. ## Agree continuity and exit arrangements Agree what happens to unused capacity, how the arrangement can change and how either party can end it. Put source-code ownership and handover responsibilities into the commercial terms. The working handover should identify the code location, setup and release instructions, access that must be transferred or removed, and unfinished requests. Before signing, ask what another developer would need to continue the work. Keep that information current as the application changes: a setup note that describes an old deployment process will be little help at handover. Explore our [PHP development](https://webvelopment.co.za/services/development/php-development/) and [custom software services](https://webvelopment.co.za/services/development/custom-software-development/), or [discuss a recurring PHP workload](https://webvelopment.co.za/contact/) with the current system, expected priorities and operational responsibilities. ## An illustrative first-cycle agreement Imagine a business with an inherited PHP application and a queue containing a failing form, a request for another form field and an intermittent integration problem. Everything arrives marked urgent. Before allocating work, we would ask the client decision-maker which business activity each problem affects and what can wait. The form failure can be treated as a defect once its expected behaviour and reproduction steps are clear. The extra field is an improvement: the reviewer needs to say what information it should accept and where that information should appear. The intermittent integration problem may need investigation before anyone can estimate a correction. If it is causing an operational interruption, its handling also depends on the incident arrangements actually agreed. For the form correction, write down a sample submission, the result expected and who will check it. After the change, the reviewer should be able to repeat that submission in the agreed environment and compare the result. Include the checks performed and any remaining release steps in the handover. If there is no suitable place to test safely, discuss establishing one as part of the work before treating the correction as ready to release. At review, look at what was accepted, what was interrupted and what waited for an answer. Perhaps the form correction is ready but the extra field is waiting for a decision about where its data belongs. That is a preparation issue to resolve before adding capacity. If incidents repeatedly displace the queue, review the support responsibilities and the amount of planned development the arrangement can realistically accommodate. Keep the code location, important dependencies, access and outstanding work in the handover record as you go. This is a hypothetical planning example, not a previous client engagement. Carry-over, allocation and availability still need explicit agreement for your application. ## Allocate a sample month without promising output The following is an illustrative planning check, not a reported client result. | Decision | Evidence to prepare | | --- | --- | | Planned improvement | Describe the ticket, reviewer and test evidence needed before calling the change complete. | | Operational interruption | Agree how a newly reported incident changes priorities and who can approve that change. | | Maintenance dependency | Check the installed PHP branch and dependencies before promising a feature against an unknown environment. | Put the three decisions beside one another when planning the month. If an interruption takes priority, identify which improvement moves. If the installed environment is still unknown, resolve that dependency before treating the feature as ready for delivery. The exercise should show where capacity will go and what needs an answer, without turning a request list into a promised quantity of completed features. Use these checks to [discuss the relevant delivery scope](https://webvelopment.co.za/services/development/php-development/) or [bring a specific question to Webvelopment](https://webvelopment.co.za/contact/). ## Practical questions A few useful answers before you decide. ### What should the first retainer period establish? It should establish what application we are taking on, what condition it is in, who can grant access and who will review changes. Agree how requests enter the backlog and how releases are approved, alongside any ready work selected for delivery. Make onboarding visible rather than assuming a feature volume before the application has been assessed. ### Can every request be marked urgent? That removes the distinction prioritisation is meant to provide. Your nominated owner needs to choose what displaces other work and understand the consequences. The developer can explain impact, but should not infer business priority from the loudest or latest message. ### Should investigation consume development capacity? Yes, where the agreement includes it. Give the investigation a question, a time boundary and an expected output. For the intermittent integration in the example above, that output might explain what could be reproduced, what remains unknown and what evidence is needed next. You should be able to use the findings to choose the next step, even if a correction is not yet ready. ### How do we handle a change that expands after inspection? Explain what inspection revealed, which part of the original request it affects and what choices follow. Your nominated decision-maker can then narrow the change, move other work or request further investigation. Update the backlog and estimate accordingly so both sides are planning from the same information. ### Does a retainer guarantee emergency response? Only if specific response obligations and availability are included. A recurring fee alone does not define monitoring, incident ownership or local-hours cover. Clarify those responsibilities so business operations do not rely on a service that was never actually agreed. ### What should happen at a retainer review? Walk through completed changes, work waiting for review, interruptions and unanswered questions. Then choose what happens next: prepare a request properly, change a priority, investigate a recurring failure or revisit the allocation. Hours used are useful context; the review should also explain what those hours produced and what prevented progress. ## Implementation reference Consult [PHP’s current supported-version information](https://www.php.net/supported-versions.php) when reviewing the application’s installed PHP branch and maintenance needs. The planning example above is Webvelopment’s general guidance; it is not a client case study. Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget. Keep exploring ## Keep the right things connected. [Development ### PHP Development Fix bugs and add useful features to an existing PHP application, with attention to its business rules, database, integrations and release needs.](https://webvelopment.co.za/services/development/php-development/)[Development ### Custom Software Development Plan custom software around the tasks your staff and customers need to complete, with clear rules, permissions, integrations and handover.](https://webvelopment.co.za/services/development/custom-software-development/)[Connected solutions ### Extend your team with accountable development capacity Choose outsourced development for a defined project, an evolving backlog or agency overflow, with clear responsibilities for review and release.](https://webvelopment.co.za/solutions/outsourced-development/) Let’s move things forward ## Start a conversation Tell us what you are working towards. We’ll help you find a practical next step. [Discuss this planning question](https://webvelopment.co.za/contact/)