Webvelopment
South Africa · Development

PHP Development in South Africa

Fix a PHP application your South African team relies on. Scope inherited code, check business rules and prepare the change for release.

Let’s talk

Improve the system while respecting the work it supports

Application code displayed on a desktop monitor.
Illustrative photography · Karl Pawlowicz / Unsplash

Your team may rely on a PHP application whose original developer has moved on. Perhaps a report produces the wrong total, a staff member needs a different permission, or a familiar workflow now needs an extra step. We help you work out what needs to change and what the people using the system still depend on.

Start with the business task, even if you cannot yet explain the code. Show us where the problem occurs and identify someone who can confirm the correct result. Assessment then needs authorised access to the code, environment and available documentation. The people responsible for the system must arrange repository access, hosting permissions and release approval.

Scope a reversible piece of work

An initial assessment can cover how the code is organised, its dependencies and whether we can reproduce the reported issue. From there, we can propose a first change: a defect fix, a workflow addition or an improvement to an authorised integration. What we can commit to depends on the stack and the condition of the application.

It helps to separate the immediate request from the wider list of concerns. Fixing a report does not automatically include replacing the hosting, upgrading dependencies or migrating data. Those changes need their own scope, and a code review does not amount to security certification. We also need to understand how the prior working state could be restored before proposing a production release.

Check behaviour with business examples

Bring examples of what staff enter and what should happen next. For a calculation, include the expected number and the rule behind it. For a permission change, explain which staff role should gain access and which should remain restricted. Include an exception as well as the ordinary case so that the reviewer can see whether the change handles both.

We use those examples, existing checks and relevant regression checks to assess the change and the surrounding behaviour it must preserve. The handover should explain what changed, what was checked, any deployment dependencies and the recovery steps if the release fails. Production access and approval stay with the agreed owner. Support hours and urgent-response arrangements are agreed separately.

Give the operating team a reviewable change record

A useful brief can be short, provided another person can follow it:

  • Describe one incorrect or missing behaviour, where it occurs and the expected result.
  • Name a staff reviewer who can explain the normal case and an exception.
  • List the surrounding behaviour that must still work after the change.
  • Confirm who can approve the production release and how the prior working state is retained.

Keep the examples with the change record. They give the reviewer something specific to check and help a future maintainer understand why the code behaves that way.

Common questions

A few useful answers before you decide.

Can you quote from a feature description alone?
We can discuss the request and what it might involve. For an unfamiliar application, we may first need a discovery phase to inspect the code and environment before giving a reliable implementation estimate. Include known errors, setup instructions and access limitations in the enquiry; they help us identify what still needs investigation.
Can the current hosting remain in place?

Possibly, but we need to assess the application’s requirements and the access available before confirming that. Tell us who manages the hosting and whether there is an environment where changes can be checked before release.

The global PHP development page covers the technical service. Discuss a local PHP brief with the application purpose, the change required and the person who can validate it.

Rehearse the change with the business reviewer

For example, suppose an internal application calculates an invoice total incorrectly when a discount is entered. A useful starting point is a permitted example showing the entered amounts, the displayed total and the total your finance reviewer expects. Add an invoice without a discount so the reviewer can also check behaviour that should stay the same.

Before implementation, clarify which rule the business wants applied. If staff disagree about the expected result, that question needs resolving before a developer can implement it. The proposed change can then be demonstrated against those examples, with the release environment and recovery steps understood before production work. This is an illustration of how to prepare a request, rather than a claim about a delivered project or an unseen application.

Bring the source and setup information you are permitted to share, known issue history and any supplier dependencies. Tell us whether the immediate need is a defect fix, a new capability or broader modernisation. These can overlap, but agreeing the first task makes the work easier to estimate and check.

More questions for a local PHP engagement

A few useful answers before you decide.

What if only one employee understands the system?
Involve that person in the assessment and ask them to walk through the affected task, including the shortcuts and exceptions other staff may not know. Capture the relevant rules and examples where other authorised people can find them. One conversation will not document the whole business, so start with the behaviour being changed and flag anything that still depends on that employee’s knowledge.
How do we deal with a previous supplier's accounts?
First establish who owns the source, hosting and relevant subscriptions, and what access they can legitimately provide. Ask for appropriate access through those owners rather than passing around another person’s credentials. If ownership or account control is unresolved, the business may need to settle that relationship before we can estimate or release work beyond the permitted assessment.
Must the first project include all known issues?
No. Choose the first scope around an operating need that can be demonstrated and checked. Keep other findings on a separate list so they are not lost. A staged plan should say what each phase changes and why; grouping every defect, upgrade and feature into one release can make it harder for staff to tell whether the original problem has been resolved.
How should staff report a new problem?
Send the steps taken, the expected result and what happened instead through the agreed channel. Include permitted example information that helps reproduce the problem, without secrets or unnecessary personal records. The maintenance or project agreement determines how reports are received and prioritised; submitting a report does not create an immediate support commitment.
What evidence should the business keep after release?
Keep the accepted examples, release note, known limitations and explanation of changed behaviour together in an appropriate shared location. Include the person responsible for the change. Someone investigating the same workflow later should be able to see what staff checked and what was agreed, without having to find the original reviewer.

Prepare your next conversation

Tell us what the application helps your staff do, who owns it and which change would help first. Include a description of the problem and who can check the result. You do not need to send credentials in the initial enquiry.

Compare a wider software brief · Assess an inherited technical unknown

Discuss your PHP development brief.

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.

South Africa · Contact

Contact Webvelopment About a South African Project

Discuss a South African website, software, eCommerce, marketing or creative brief with Webvelopment, including goals, current tools and the people reviewing delivery.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk