Webvelopment
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.

Let’s talk

The problem we help solve

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

Your PHP application may still do the work you need, while one part makes the day harder: a quotation needs a new approval step, an export leaves out a useful field, or staff have to correct the same record twice. We help define and implement changes around the application you already use.

If you have inherited the code, we first need to understand how the affected task works today. That includes the rules staff rely on, even when those rules exist only in someone’s notes or memory. From there, we can discuss whether to repair the current code, extend it or replace a particular part.

What we can deliver

  • Codebase and dependency review focused on the task you want to change.
  • Bug investigation using an example of the wrong result and what should have happened.
  • Business features such as an approval step, an additional search filter or a revised export.
  • Database and API work to support the agreed feature or exchange information with another system.
  • Release and maintenance planning, including the checks needed before staff use the change.

We agree which outputs your project needs. For an export change, for example, that could mean the revised file, examples showing the right rows and values, and instructions for the person who releases it. Your team should also name someone who can confirm that the result fits the way the business works.

Technical leadership

Our technical leadership combines practical PHP development, enterprise integration and digital strategy experience. Willan Theunissen’s professional background explains how that experience supports discovery, implementation and maintainability.

How we approach the work

We start by getting the application running in an agreed environment and following the workflow you want to change. We look at the relevant code, existing tests, dependencies and release arrangements before estimating the implementation in detail.

Keeping the current approach may make sense for a small correction. A larger change may need work on the surrounding code first. We explain what each option would involve, what it leaves in place and how we would check it. The first release should address an identifiable business need, with any wider work priced and discussed separately.

Who this is for

This service is for businesses running an existing PHP platform and agencies needing implementation support. It is particularly useful when you can describe the task that needs attention but need help finding where and how to change it in the code.

Boundaries to agree early

Before work starts, we agree authorised access, third-party licences and which software versions the engagement will support. We also need to know who manages hosting and who can approve a release. Security remediation requires a separate assessment; a review of one feature cannot establish the security of the whole application.

Questions before we start

A few useful answers before you decide.

Can you take over an existing system?
We can start with an assessment of the existing system. We need to establish access, how the application runs, the condition of the relevant code and what a release involves before agreeing ongoing delivery. Bring any setup notes and known issues, including work that a previous developer left unfinished.
What do you need from us?
Tell us what people use the application for and what you want them to be able to do differently. An example of the affected screen, report or record helps, with private information removed. Include an authorised technical contact; we will arrange repository or environment access separately once the assessment scope is agreed.

Use a business transaction to understand inherited code

For example, suppose your application creates quotations and records their approval. You want to change a calculation. We would follow a sample quotation from entry through approval and export, checking where the calculation is used and who can confirm the expected amount. We would also ask what should happen to quotations that were approved before the change.

That example gives the review something concrete to cover: a new quotation, an existing draft and an already approved record. A useful first release might correct the calculation and include checks showing how each behaves. This is an illustration of how we would investigate a change, rather than a description of a delivered project.

Bring operating knowledge into the technical review

Alongside authorised source access and environment information, bring someone who uses the affected workflow. Ask them for an ordinary example and an awkward one: a cancelled quotation, a missing reference or a record that needs correcting after approval. Their expected results help us distinguish a bug from an undocumented business rule.

Where the code and staff expectations disagree, we ask you to settle the rule before implementing it. Reading the existing code alone cannot tell us which behaviour the business wants to keep.

Prepare a reproducible change request

  • Identify one affected business record and remove identifying information from the example.
  • Describe current and expected behaviour, including the roles allowed to make the change.
  • List environments, deployment ownership and known dependencies before promising a release date.

Further PHP engagement questions

A few useful answers before you decide.

Can an inherited application be improved without a full rewrite?
Possibly. If we can understand and test the affected behaviour, a focused repair or extension may be enough. We would compare that with replacing the affected part, considering the dependencies, release work and who will maintain it afterwards. A full rewrite needs its own justification; the age of the application alone does not decide the scope.
What does an initial code assessment establish?
An agreed assessment can establish how the application runs, which components it depends on and where the workflow you want to change is implemented. You should receive findings, practical options and questions that still need answers, with a clear account of what was inspected. A narrow assessment cannot establish the condition or security of every part of the system.
Why do reproducible business examples matter?
They let the business reviewer and developer discuss the same behaviour. A vague report that totals sometimes look wrong is harder to investigate than a permitted example showing inputs, expected output and the observed difference. Use synthetic or appropriately handled records. The ability to reproduce the problem influences both the investigation and the acceptance plan.
Can dependency upgrades be combined with feature work?
They can be planned together, but their consequences need assessment. An upgrade may change behaviour beyond the requested feature and introduce additional testing or hosting requirements. Separate the decisions where that makes risk easier to understand. Confirm which component versions are actually in use rather than relying on a label in an old document.
How should a database change be reviewed?
Define how existing and new records will behave, how a migration will be checked and what recovery is available if release fails. The responsible owner must approve handling of production information. Review the application’s reading and writing paths, not only the migration command, and record any compatibility assumptions that affect the deployment sequence.
What makes a maintenance arrangement different from a project?
A project defines a result to be accepted. Maintenance needs ongoing intake, prioritisation and a boundary for updates or incident work. Establish the expected capacity, supported environment and response process. Taking over source code does not automatically create an unlimited support commitment or remove the need for business approval of changes.
What should be documented at handover?
The handover should explain how to run and release the application, who owns the accounts, what changed and how to check the result. For a revised quotation workflow, that could include sample inputs and expected totals, along with any rules for older quotations. Include known limitations and unresolved questions so another authorised person can continue the work without reconstructing private conversations.

Prepare your next conversation

Start with the task you want to improve: what happens now, what should happen instead and who uses it. Tell us whether you have the source code, setup instructions and a technical contact. We can then discuss a useful first assessment and arrange authorised access separately.

Discuss a Laravel application · Scope an inherited-system assessment

Discuss your PHP application.

Enterprise energy data orchestration · Secure multi tenant applications php.

Keep exploring

Keep the right things connected.

Our expertise

Bespoke Development

Plan business software around the work people need to do: choose an application, eCommerce change, PHP update or integration, with a clear first release.

How we work

Clear decisions. Reviewable progress.

How Webvelopment scopes, designs, builds and hands over digital work with clear ownership at every stage.

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