Due to spending a lot of time at conferences this year, I’ve been thinking about how the advice we give from the stage, or in our writing, scales up and down to the various contexts in which people are developing for the web.

The company I founded in 2001 has a long history of working as an outsourced development agency, working for small design companies. We spent years being thrown Photoshop documents, pictures of websites, and being expected to develop them. In 2011 we started to move away from the model as we couldn’t deliver the sort of sites we wanted to deliver, do the standard of work we wanted to do, when the people we worked for just wanted to draw a website and then not play any further part in the process.

All that said, this model of tightly scoped roles is reality for many small agencies and individual freelancers. We can preach from a conference stage all we like about the ideal way to develop a site, about best practice, about developers sitting alongside designers. From experience however, and from hallway conversations I know that many of those we talk to essentially work alone. When they get a project that is outside their expertise they have to either turn it down, or outsource bits of it.

I have been that outsourced developer. I still work in that world through our product Perch. Many, probably most, of our customers are individuals or tiny design agencies. Many of them rely on products like Perch not just as a content management system, but also to deliver the site itself. The CMS provides functionality that they would otherwise have to outsource to a developer.

This is for everyone, the web is for everyone. Creating good websites is possible on a tiny budget just as much as on a grand scale. However speaking from personal experience it can be easy to write advice off as not for people or companies like us.

While we are exploring best practice for the web of today and tomorrow, I am keen to ensure that we don’t stop looking for ways to create tools and processes that help the lone designer or developer collaborate well with others. How do we distill the lessons learned in big teams, where people can work alongside each other, into tools and working practices that function when these people can never physically meet? How do we take the essence of best practices from large budget sites — and allow the creators of sites with tiny budgets to benefit from them?

License: All rights reserved