I provide web development and associated services to a small number of clients I’ve picked up over the years. This post is based on my humble experience freelancing and is aimed at those who, like me, are providing a service on a small scale.
Every so often I receive a question from a past client. I try to get back quickly and generally, I don’t mind as it feels good answering little questions and helping people. But those quick email exchanges add up and without an ongoing agreement, it’s a cost that I (and I imagine others) absorb because often those questions lead to billable work.
This lead to an interesting situation recently where I received a question worded with a subtle difference:
“Can you point me in the right direction?”
Many clients don’t understand the troubleshooting process that web developers and IT folk undergo in order to determine the nature of a problem. I imagine this isn’t unique to this industry. There’s value in knowing where to look and how to resolve a problem.
In many cases, it’s the troubleshooting process that accounts for the majority of time spent resolving an issue. Sometimes, the solution comes in the form of a simple flip of a switch, ticking a checkbox that’s buried deep within a settings interface. It might take an hour to find it, but it’s there.
Website owners should plan on paying a monthly maintenance fee to cover the costs associated with troubleshooting, updating and problem resolution. Unfortunately, this is easier to conclude with hindsight. My younger self wasn’t aware that these simple content sites might stick around for five, even ten or more years.
The takeaway? Make it a point to charge your clients for ongoing maintenance. I suggest discussing maintenance early on when you take on a new client. Bundle basic support along with CMS updates and regular backup. Then you can cover those quick questions which would otherwise be covered out of pocket.
WordPress makes it easy to put a website together but it doesn’t necessarily make web development easy.
For many, WordPress works out-of-the-box and with the vast ecosystem of both free and low-cost plugins, beginners can patch together a reasonable website packing serious functionality within a short space of time, with minimal upfront cost.
The mission of the open source WordPress project is to democratise publishing and of course, in many ways it has achieved this goal. However, the simplicity and low barrier to entry hide the true cost of web development.
Mario Peshev wrote about value a while back after receiving an enquiry. The client outlined their requirements, to alter a plugin to include their bespoke functionality. The client laid out their expectations, “the plugin costs $25 so I estimate the change would probably cost around $15”. It’s clear this client undervalued the work involved in custom development.
WordPress is a great tool to get a project going quickly. It’s fairly rewarding to work with. A lot can achieved out-of-the-box and you can end up feeling that anything is possible! However, once you stray outside the basics of strapping a theme together with a few plugins and need something custom, that’s when you realise web development is complex and WordPress is no different.
Something a little different for my blog… I’ve written a few pieces for findmyfood over the years, mainly sharing my more successful home cooking attempts. This post is my first-ever attempt at an in-depth food review. Written following a visit to a newly opened restaurant in Shrewsbury.
Walking into the restaurant we passed an impressive BBQ Lovin’ neon sign on our way to the reception area where we received a warm welcome. The reception area was nicely decorated, the walls lined with a wide ranging selection of barbecue sauce bottles…
This is a post written for the iWeb blog battling the misconception that Less is “just another thing invented to make something that was once simple more complex… technical developers like to attempt to solve problems that don’t really exist”. The post looks at why CSS preprocessors are useful and includes a quick write-up of an interesting project John Cotton presented at WordCamp Lancaster UK 2013.
CSS (Cascading Style Sheets) is the language used to define the layout of web pages. The language is fairly simple, you target an element using a selector and then define how it should look with the available properties. It’s an approachable language which has it’s advantages in terms of opening up the web to those without a background in computer science…
I spent my Saturday at the first WP Contributor Day. Sold as “An one day event where anyone & everyone contributes to WordPress”. The event, held at TechHub, Manchester was setup and organised by Jenny Wong following a discussion at WordCamp London 2013.
Often, knowing where to start is a challenge. And WordPress is no different. It’s a giant project and for me, I saw this day as an opportunity to push me to finally get involved. It was kicked off by an introduction from Jenny, followed by talks from WordPress co-founder Mike Little and web accessibility expert Graham Armfield.
Following the talks, we split into groups. Mike Little introduced Vagrant, and in particular the Varying Vagrant Vagrants (VVV) project. The setup gives developers a kickstart in getting WordPress running locally (without the need to upload files to a hosting account).
Feeling pumped and definitely over-confident, already having used a VVV setup for a while, I sat with a group of developers and looked through Trac for a suitable challenge to tackle. I felt a bit lost to be honest. There were four unclaimed “Good First Bugs” (which taking a look after the event, I see that they all remain unclaimed). I had the same issue Mike experienced earlier during his introductory talk. Reading the history of each ticket lead to a dead end, either the ticket had been actioned or it was questioned whether a fix was even required.
I felt like I was missing a step in between and quickly jumped ship, joining up with a group lead by Graham Armfield looking at accessibility in WordPress. This proved immensely useful. Graham guided us through Trac, looking at a number of issues he’d raised. He shared and demonstrated some of his vast knowledge of the world of accessibility followed by an introduction to his SVN workflow, downloading and applying patches to his local copy of WordPress to test whether an issue had been resolved. Unfortunately, none of the patches could be applied! Despite the fact he’d picked out the tickets in advance, the WordPress codebase moves so fast that all the patches resulted in merge conflicts. However, it was potentially more valuable to see Graham go through a less than perfect example to see the process. In this case, Graham updated the tickets, asking for the patches to be refreshed.
As someone who generally needs a push to get involved, a contributor day is a daunting prospect. However, I got into the flow and found my feet. The day was relaxed and everyone very welcoming and friendly. I look forward to future events and getting involved in WordPress development.
Could future events be even better for people like myself? I guess it comes down to the intended focus, contributing to WordPress or spreading knowledge and introducing beginners into the loop (there’s a WordPress pun in there somewhere). I believe we can have both. Perhaps future events could use more structure. A system of buddying beginners with more seasoned developers, with more “Good First Bugs” or a selection of Trac tickets reviewed beforehand, giving beginners a chance to get stuck in.
Overall the day was enjoyable and there were wins for WordPress. I believe Jenny has been roped into organising another Manchester contributor day and she’s keen for the model to spread to other areas to get more passionate people involved in contributing to WordPress.