Listing what runs on your site is more alarming than it should be.

What we changed

Every feature has a running cost, even when nobody touches it. It needs testing on each upgrade, explaining to each new editor and checking in each review. When a client asks for something small, we ask who will look after it in two years. Sometimes the honest answer is that it should stay a good idea.

Clients rarely remember the clever parts. They remember whether the site stayed up, whether the invoice matched the estimate and whether someone answered when it broke. We try to write code with that in mind. A plain solution that a tired person can repair at the end of a long day beats an elegant one.

If you cannot explain why it is fast, it is only fast today.

Priya Raman

How we tested it

Writing it down was the last step and possibly the most useful one. A short note about what we tried, what failed and why we stopped has saved us more time than any tool. When this comes up again, and it will, someone will search the repository, find these paragraphs and skip the whole expensive afternoon.

We started by reading the code rather than the documentation, because the code is what runs. Most of the surprises in a WordPress project live in the gap between what a function promises and what the theme actually asks of it. An hour with the templates open told us more than a week of status meetings ever had, and it gave us a list of real questions to bring to the client.

What we would do differently

The first measurement is always the most useful one, even when it is rough. Write down the query count, the page weight and the time to first byte before you change anything. Without those numbers you cannot tell an improvement from a coincidence, and three weeks later nobody will remember what the site felt like before you touched it.

Pages: 1 2