Search the site:

Copyright 2010 - 2021 @ DevriX - All rights reserved.

6 Things We Learned In 2015 as a WordPress Agency

In 2015, we published a business recap of 2014  which described the valuable lessons we’ve learned as a growing WordPress agency. We faced some serious challenges in 2014, ones that taught us a lot. We took note and restructured our process in order to keep doing what we love while growing steadily.

It’s early 2016, and our team of over twenty is actively working on several high-end projects, helping businesses with WordPress development, business growth, systems architecture, marketing and creative work, delivering great results and maintaining a good portfolio of ongoing projects. This was possible thanks to some lessons that we’ve learned over the past year, and we’d like to share them with our fellow WordPress consultants and agencies who are also striving to grow, build diverse distributed teams, and work with incredible clients across the world.

There’s much more planned for 2016, and some ideas will work while others won’t, which is why we’re looking forward to the next challenges to be tackled over the coming year. Here is what helped us improve our business and team growth so far.

1. Proposal Templates and Sales Funnel

Landing new clients and partners is a process that requires involvement by everyone participating in the conversation. However, understanding client requirements is a process which is incredibly time consuming, requires a number of calls, going back and forth via email and IM, and asking all sorts of questions, reviewing code base to date, and preparing a lengthy custom proposal with a contract as a final step.

Late in 2014, we had received a good number of inquiries each month, but many of them didn’t take off due to a lack of sufficient budget, miscommunication, lack of understanding of our service model, and other various reasons. Additionally, all of the above took forever to prepare, and even interrupted our development workflow. And when you spend dozens of hours (or more) preparing a proposal, which doesn’t work out, it ends up being a massive waste of time and resources.

WordPress maintenance packages

That’s why, at the end of 2014, I spent time defining our main WordPress development service offers, outlining a format for landing pages including the basis of our solutions, and standardizing a questionnaire for custom one-off gigs. The main types of work that we deal with are the following:

  1. WordPress development retainers
  2. Large custom web solutions
  3. Ongoing maintenance

Our retainers and maintenance plans are now defined in detail, with different options for different types of businesses. Since custom web solutions vary and we offer various services as a part of the package (development, design, business growth, systems management and marketing), we prepared an initial inquiry questionnaire that answers the majority of the questions that we would ask each and every client, thus drastically cutting down the pre-sales time.

Given the feedback from our clients in 2015, we’ve realized that this had helped some of them understand what we do better. It also helped them define their main goals better. Clients often search for a web solution, without understanding why, and our form focuses on important business goals, researching the competition, defining UI guidelines, providing measurable data and more, which is often the basis of our proposals, too.

Speaking of proposals, having those three main service solutions ready to sell, we were able to prepare standard proposal templates and contracts for each of them. Part of the work was defining our SLA, maintenance periods, codebase ownership details and licensing, legal stuff, communication protocol, acceptable times for response, what needs to be delivered upfront, and what would be the end result when handing over the project (or monthly for ongoing deals). Our template proposals include sections for the things we do. We just delete the ones not relevant for a given project and modify the ones that we have more details about.

Once we’d automated part of that process, which allowed us to talk to more prospects, we identified our solutions better, reduced the number of non-qualified leads and cut losses from back and forth with prospects who didn’t require our services. We also officially introduced the paid discovery session plans for customers, who didn’t know what they wanted yet, where we worked closely with them and defined a business strategy for them.

2. Ongoing Business Relationships

Ongoing work has always been one of the main goals we are aiming for at DevriX, and that is only possible through ongoing business relationships. This includes two different branches:

  1. Building ongoing contracts with new clients coming to us.
  2. Build partnerships with service providers that offer complimentary services to what we do.

Ongoing Contracts with Clients

Previously we’ve accepted more fixed-fee gigs than needed, and due to the lack of proper proposals, we’ve faced various issues with constant delays, missing information or assets from clients, problematic hosting solutions (such as Yahoo!’s – yes, they actually offer old-school hosting) and more. In addition to that, clients weren’t often interested in ongoing work for their websites, and a year or two later, problems kept coming their way – hacked websites with a very outdated version of WordPress, or administrators installing vulnerable sliders and other additions that kept affecting the initial solution that we’d provided.

Now we take on very few fixed-fee gigs and sell mainly ongoing development retainers, but even the fixed-fee projects include an ongoing maintenance contract that lets us control the future of the technical stack as best as possible, while maintaining a high level of security and performance. Managing changes on staging servers, even for small clients, helps with incompatibilities and regressions, something we’re working on without pushing to production. Dealing with updates, code reviews, uptime monitoring and resource management also ensures the stability of those solutions, which used to be an internal requirement only for larger platforms.

Partnerships with Other Vendors

In late 2014 ,we focused entirely on partnerships. Our marketing department was handling the website content, link building or advertising that was bringing incoming leads, but the management team developed a strategy for ongoing partnerships.

We were able to form several strategic contracts with agencies in Europe, North America and Asia. Some of them were technical agencies that couldn’t deliver everything and preferred outsourcing the heavy lifting to us, or off-loading when there’s too much work on their plate. Others engaged in different business fields – advertising, PR, SEO, marketing, creative, hosting companies looking for a solid WordPress development partner that would adapt to their processes, help them grow, and deliver ongoing development services to their accounts when needed.

In addition to bringing in good ongoing revenue, this allowed us to broaden our business development horizons by exploring different sales, marketing and growth strategies, project management processes and legal patterns that helped us scale up. After spending time with the same partners, it became possible to take on more work from them, deliver better results and in less time. This also convinced some of them to offer WordPress development services formally on their websites and offload those leads to us.

Partnerships are the core philosophy of DevriX nowadays, and we gladly compliment our partners’ service portfolios with WordPress development work while letting them focus on what they do best.

3. Help Different Audiences

Several years ago when we first started, our team consisted of just a few people. We didn’t have enough manpower to tackle large enterprise projects, and didn’t provide various services in order to sell a complete package. With enough perseverance, we were able to grow, increase our skill set, and build a team that now works on high-end projects, including large multisite platforms for automotive manufacturers, large media portals, scalable Software as a Service solutions and more.

That, however, changed our management processes as well – introducing people with different skills from different countries, people responsible for them in the form of management or team leading, QAs, internal tools and systems, and additional costs to make this all work in the long run. This quickly became too costly for smaller customers, and the lack of a public portfolio due to the numerous NDAs that we’ve signed made it harder for new leads to take a leap of faith with the mid-five figures (or more) contracts.

In order to become more flexible in those cases, we’ve discussed what could be done for clients in different audiences. Defining our buyer personas and classifying the different levels of clients was an important step for moving forward.

We have specialized in several directions, such as building SaaS solutions (with different payment and feature plans), large multisites, custom migrations from different platforms (PHP, Java, Python, .NET) and large custom projects integrating all sorts of 3rd party APIs. This move allowed us to build separate processes for each of those, extract certain reusable components and increase the level of experience in our team members. This also allows them to continuously deliver more in less time with fewer hiccups on the way.

We have identified ways to decouple a main service core of work that we need to do for each and every client, and defined other sub-services that we could upsell or combine on top of. For example, building a large technical WordPress platform and hosting on a reliable infrastructure is generally our main thing. However, we could offload the hosting to a managed WordPress hosting provider, delegate the design to someone else, and not take on the marketing and growth efforts.

We have been experimenting internally with different tools and plugins through our verification process and those can now be used in projects without us having to bother with performance or security (or building them from scratch). We’ve formed relationships with many of their authors by contributing back patches or having a direct point of contact for reporting issues or discussing potential new features.

For clients that were willing to pay for the full suite of services, but had a hard time committing to a large amount upfront, we’ve polished our WordPress development retainer plans in a way that allowed them to sign up for a “trial” and see how we work, pay monthly for each milestone instead of committing to the full amount early on. Additionally, this allowed us to implement new requirements during the development process, redefine goals, build iteratively (and let the client decide which component needs more work or features, and which one is ready), and generally save them a whole lot of money while giving them the flexibility to add or remove things during the work process.

Some of our clients started with a 10-hour per month maintenance plan, which was soon converted to a 40h/month retainer, others jumped from 40h/month to 100h/month. Some initial negotiations that were for $10K MVP projects are now in the mid-five figures plus, thanks to the opportunity to provide ongoing work month by month, showing incremental additions built with flexibility and extensibility in mind, launching MVPs and iterating based on user feedback, and constantly introducing improvements to existing systems.

4. QA is Invaluable

Our first QA hire was in 2014, but he was only involved in testing our main SaaS project that we were working on back then. As the number of ongoing accounts kept growing, we realized that QA is an essential unit in our process. We hired another QA and an assistant helping with setting up demo pages or listing down features, helping with demo schedules and such.

With a consistent QA staff around, we are now able to assign milestones to developers, let them work on highly decoupled tasks, and assign the work for testing to our QAs. The QA process includes pulling latest versions from Git locally, testing different branches, monitoring logs and reporting all sorts of regressions or incomplete features that need edge cases cleaned out. In addition to testing different environments (including the staging server), we are able to catch various gotchas between server versions, hosting environments, memory limits and more.

That improved the overall quality of our products and freed up some development time so that our WordPress engineers can focus on solving problems and implementing features while someone is constantly trying to break their work in the meantime. QA also includes mobile testing and playing with different browsers, which occasionally leads to follow-up CSS fixes or even switching entire libraries that don’t support media for iOS or certain browsers.

5. Communication and Documentation

Having a team of 5-8 people is manageable, but as the team grows, and people with different skill sets or experience, work on more projects, managing all of them quickly becomes a nightmare without the right process and tools in place.

Last year, we switched to HipChat for internal communication, created rooms for each project and each of our teams – developers, designers, marketers and management. We have integrated some of the services we use for each room such as Asana or GitHub, pulling the latest commits, tasks, pull requests and issue comments, which made it possible to keep the context in one place, and work with each team (per skill or project) in a much more organized manner.

We have also defined a cleaner process for project management in Asana, using due dates, various labels for priority, and utilizing the Team Calendar in order to monitor the bigger picture for weekly sprints. Introducing kick-offs and regular chats keeps the people up to date, aware of when demos are approaching, bouncing ideas off each other, assigning tasks to other team members and communicating internally. This ensures that we have more time for code reviews, workflow management, answering important architectural questions or helping with specific features.

Recently we’ve started documenting our projects as well, which provided us with a structured way to describe the project growth in real time, new features built every two weeks, ongoing things that needed to be handled in future. Those documents are available to people who join a new project, in order to reduce the amount of R&D by having a detailed overview of the project, progress, goals, team members responsible for features and more.

6. Checklists

Great speakers often say that “bullets are dead“, but they are incredibly helpful in certain cases, including defining long workflows with a large number of simple steps.

We’ve established a number of different processes for different parts of our business – the sales funnel, setting up a new project, delivering a web solution, deployments, hiring new people, introducing team members to a new project etc. However, dealing with a lot of different departments at the same time, distributed across a number of different projects, turned out to be challenging – time-wise, and keeping track of the little details.

We dug deeper and broke down the larger steps of the business process into separate components, consisting of a checklist for each of them. Some are related to hiring – a list of professional and desired soft skills, a breakdown of company goals – and the mission defined in a way that we can use during interviews to assess people in detail. Same goes for preparing a demo or setting up a project – there’s a lot that should be done for each of these every time, some being larger as “creating a new private GitHub repository” through “send documents X, Y, Z to the new team members” or “add this to .gitignore”.

Adding specific checklists for testing, making sure that internal folders are not a part of the repository, emails are being changed or certain scripts are ran everywhere, ensures that we don’t forget the small yet important details due to a hundred small steps that we have to take every single time.

Bonus: Automation and Reusability

That last bit is not really revolutionary per se, but last year we actually started to plan for both automation and reusability efforts. As a part of each internal process, we identify key things that should be automated, as well as potential components that we can reuse or build and extract as modular elements from there on.

Basically the main difference is that we spend actual predefined time figuring out what can be reused in  different scenarios, and what are the steps that waste a lot of time and can be automated. Some were not a problem when we were a smaller team, but if 8 people worked on a project and needed to perform a manual action 5 times a day that takes 6 minutes, then this results in a total of 4 hours that are wasted every day. That makes you think differently and plan better upfront.

It’s also important to establish how long it takes to build each, or how long it takes to make a web feature extensible. Once establishing that, we allocate internal time for improvements and flexibility which is done outside of the hours paid for by a client.

We’ve introduced additional automation and reusability layers in our internal and external processes. From a standardized continuous integration provisioning script on a custom cloud instance per project, through to templates for different project types or demo data for delivery. Building a collection of trusted plugins and libraries that are well tested and which can be reused without affecting stability or scalability, optimizing the communication processes, automating reporting as best as possible, using various tools to support our process.

We’re using various Zapier integrations across Asana, GitHub, HipChat, WordPress for certain actions, including Gravity Forms submissions, various reporting tools and others. We do have two application and system monitoring platforms running and tracking web solutions, and have integrated a nice UI comparison tool running image analysis over different snapshots of the same website.

Our CRM is a custom project built on top of WordPress that we’ve been developing over the past year, and keep integrating with external tools and systems, extending the reporting mechanism for better end process reviews. Our team also interacts through an internal BuddyPress instance which Stanko connected to HipChat for posting status updates and comments. We’re connecting our systems together and saving a lot of time from copy-pasting or context switching, building custom bots triggering activities through 3rd party services and performing automated business-specific monitoring for certain websites.

We have learned a ton in 2015 and have to act fast in order to adjust to the company growth. 2016 has just started, but we already have two new hires and a million things going on, including new partnerships, additional process improvements, a backlog of things planned over the next 2-3 months and so much more.

If you’d like to reach out, don’t hesitate to post a comment below, reach out through our Contact Form or ping us on Twitter, and we’d be happy to follow up!


Leave a Reply

Your email address will not be published. Required fields are marked *