How We Approach a PHP Build

We start with the people doing the work

Not with the specification and not with management's description of the process. With whoever actually does it, watching them do it, asking why at each step.

The process as documented and the process as performed differ in almost every business we work with. Building for the documented version produces a system nobody uses.

Something in production early

One workflow, working, in front of real users within about six weeks. Everything after that is shaped by how they actually use it rather than by how we assumed they would.

It also means that if something is wrong, we find out in week six rather than in month four.

Four things we insist on

1. Your repository, your credentials — without exception
2. Tests around the calculations and the money paths
3. A deployment process, not file uploads
4. Business logic separate from the framework, so it is testable and portable

What we avoid

• Building what a product already does well
• Specifications written as screen layouts
• Big-bang launches with no earlier user contact
• Frameworks or patterns chosen for their own sake
• Anything that makes leaving us difficult

How we communicate

A weekly note on the same day: what moved, what did not, what we need from you, and whether the date has changed. Short and honest.

If something is going wrong, you hear it that week rather than at the deadline. That is the whole of our project management philosophy.

Frequently asked questions