Introduction

Over the past 12-18 months, as Shopify Plus has continued to grow for bigger and more complex retailers, I’ve had a number of clients that have decided to take their development in-house, for a variety of reasons and with varying impacts in different areas. This seems to be a bit of a trend with Shopify Plus at the moment and even with new projects, people are very aware that it’s far easier to create an internal development team for Shopify / Shopify Plus than it would be with a platform like Magento, for example.

So, I decided to write this piece, as a collaboration with my Vervaunt colleague Liam Quinn, who has a very strong technical Shopify background and experience of working with in-house teams and building development teams. The hope is that it highlights some of the challenges for internalising development and also some of the key areas that need to be considered outside of just hiring.

Pros and cons of having an in-house development team

Pros

  • More ownership of what’s being done and everyone involved has an understanding of the business / more context 
  • In theory, you can be more agile as a result of being the only client of the team
  • Can be lower cost, depending on how you’re working and the amount of work / projects being delivered
  • Better communication, able to work directly with developers via face-to-face meetings etc
  • More involvement with and awareness of other systems

Cons

  • Easy to let code quality standards drop
  • Harder to create a culture for prioritising performance, accessibility, code quality etc
  • Reliance on a small number of people (and often individuals)
  • Hard to recruit and keep strong developers
  • Can be higher cost (when you factor in all costs associated with employing full-time)
  • Able to scale up and down agency resource based on projects
  • Don’t benefit from having a bigger team all learning from each other (as with agencies)

So far, I’ve seen companies really benefit from taking development in-house, although they have had to learn to create the culture and processes around performance, UAT and accessibility. I think this is part of the learning process though and it seems to happen naturally as issues occur – obviously it’s less likely to happen at all with the right team, which we’re coming onto.

The Importance of a Product Owner / Lead

The Product Owner will manage the developers time and will be a single representative for planning tasks, managing resources, managing QA / UAT, managing JIRA etc. One of the biggest risks with internalising development is that quality drops and you gradually deviate away from processes – it’s very easy to get into the habit of doing ad-hoc releases, lose focus on performance, reduce QA effort etc – the Product Owner would need to enforce processes, checks etc.

Depending on the size of your business, this may not be the only part of this person’s job, but it’s important to have someone that’s diligent and has experience in a product owner / technical project manager capacity.

The Product Owner would also be the cross-over with the eCommerce and ops teams to coordinate tasks that don’t categorise well, such as tax configuration, shipping management etc.

Team Structure / Roles

The structure of the team will be different for different businesses, as you may have different skill-sets in existing team members and you’ll have varying levels of complexity in other systems, complexity in the Shopify site, levels of front-end work etc. One of the key things to do upfront is map out the responsibilities and an idea of workload for different areas (against your backlog and roadmap tasks) – so for example, if you’re looking to introduce lots of new (relatively simple) sites that all have different themes, then you’re going to have more work for what could be a mid-level front-end developer.

Ideally, you wouldn’t be reliant on a single person (for development), to avoid codebase becoming tied to that single person, knowledge-base locked to them and code standards and quality dropping. Introducing pull requests and code reviewing will help prevent this, but require two or more developers.  

The clients that we have that have built internal teams seem to all have a similar structure, which is:

Senior / Lead Shopify Developer

This is the obvious first hire – basically a (ideally) full-stack developer with experience of working on large-scale projects and experience with Shopify. The reason I’m highlighting bigger projects is that they will hopefully be able to lead the process of creating development workflows, will have experience with working in a structured manner, push for more modern tooling etc. The Senior Developer would work with the Product Owner around planning, managing deployments, prioritisation, managing resource etc – they would also QA code and act as the architect for custom apps, integrations and anything more complex being delivered.

Junior / Mid-Level Shopify Front-End Developer(s)

Although this isn’t always necessary (as a full stack developer could feasibly take on the front-end tasks), having someone that’s more focused on delivering high quality, pixel-perfect front-end tasks is a good person to have in a team. This person wouldn’t have the same knowledge or experience with some of the areas listed above, but they’d be able to deliver items from the backlog related to front-end, apps, basic liquid logic etc.

The requirements in terms of skills would likely change if you were to go down the headless route, more likely requiring someone with Vue.js or react.js experience. 

IT / Systems resource

I’ve highlighted this as well just because it’s important – ideally, you’d have another resource focused on other internal systems and they’d take responsibility for integrations with these systems.

Overall, before you make this decision you need to quantify the amount of work you’re looking to do in the different areas – scoping out a longer-term the backlog and roadmap will help define how much development resource you need and how this is likely to change over time.

Development Skillsets & Tooling

The following is a list of essential and desirable knowledge that an internal Shopify development team should have within its ranks, and the reason why each is so important in this context.

Essential

HTML5 – A core understanding of good markup, how it can affect performance/seo/accessibility aside from just making something visually match a design. Also an eye for when a design isn’t going to lead to functionality being as efficient as it could be.

Liquid Syntax – This is the frontend templating language used by Shopify and essential to applying any sort of logic to Shopify templates. This can be as simple as adding a “Sale” label being displayed on relevant products within PLP, or more complex like building out data-powered product recommendations. 

While it’s not too complex to pick up by someone with previous JS/Ruby/Backend knowledge, experience and a strong understanding from the start means immediate progress could be made and there would be no dip in code quality during that learning curve. Some decent resources for more context here:

SCSS – The CSS pre-processor that tends to be used for building out and maintaining stylesheets should be fairly commonplace for any frontend developer.

Vanilla JS – Certainly Javascript will be an important aspect of any Shopify site build, to what degree will be the only question. Javascript is the driving force behind anything dynamic on the site, whether that be animations or forms submitting without the page refreshing. Shopify itself is dependent on JS for a lot of its core functionality – adding to cart etc. An understanding of Javascript at least in it’s ‘Vanilla’ state will be crucial.  

Desirable

Vue.js / React – These are the two commonly used Javascript frameworks. If you already have an existing store and are looking to bring development in house, one of the early questions should be whether one of these frameworks has been used in the build because then it becomes more of an essential. Otherwise, good knowledge of these could be a benefit, if the roadmap contains the introduction of some more custom functionality. 

Ruby/PHP – The beauty of Shopify is that we don’t need to class backend skillsets as absolutely crucial. While it’s highly beneficial to have some proper backend knowledge, to do really specific things with data that might require some middleware or possibly an app creating, the reality is that with a bit of tinkering there’s already an app to cover a lot of common requirements including business intelligence or moving data in/out of Shopify to an ERP for example. 

GraphQL – Following on from the above, Shopify has definitely stepped up it’s push towards GraphQL being the way forward for anything API related. So if data manipulation and more backend focused functionality are on the roadmap, it is well worth having someone that is comfortable with using GraphQL to achieve that. 

Development Processes

Equally as important as getting the right development resource in, is making sure the processes are solid and followed properly. This section outlines how the processes within the development team should be structured. 

Task Management

There are a number of similar task management systems that do a similar thing – Asana, Basecamp, Teamwork, but Jira is really strong for managing development focused tasks across a single project. It offers a great amount of information attached to each task, the functionality of efficiently breaking a bigger piece of work into related tasks/subtasks, and the ongoing reporting of them. 

A task should begin life somewhere in a sorted backlog, which really defines the roadmap of the site. Consistency and clarity of information is key to a solid process and each task should at least be made up of:

  • Unique Identifier
  • Due Date
  • Time Estimate
  • Title
  • Clear description of what needs to be achieved for the task to be signed off.
  • Related/Dependent tasks

QA/Testing

Once a task had been picked up from the backlog and been through development, there should be a robust QA/Testing process to ensure the quality of everything that goes live. The first step to achieving this with an internal team is to use automation as the first line of defence. This could take the shape of some of the following:

  • Pull Requests within GitHub/Bitbucket being utilised by the developers to look over and have the opportunity to feedback on every piece of code before it’s merged into the codebase.
  • Using tools such as Circle CI, Cypress.io, Jest a suite of Javascript tests can be created that automatically run on each code commit, and only allows merges to take place when the tests have all passed.
  • The same principle can be used for snapshot testing, which as it sounds compares a snapshot of areas of the frontend to flag anything that may have wrongly changed within a code change.

Following this automated first line of defence, there should be a product owner aside from the developer, who sanity checks that the output being delivered is as expected against the brief. Going back to task management, the more clarity on task descriptions – the less chance of any pushbacks being required here.

Deployments

Again a set process should be in place and consistently followed here. Most developers with experience within successful teams will be familiar with most/all of the following:

  • Deployments should happen between set thresholds. The opinion of the product owner will always test this at some point, but it is safest all around for this to be observed strictly – to avoid disasters happening around out-of-hours times. “No deploy Fridays” is quite a common one, but certainly not putting a site Live on a Friday is good practice. As is having a cutoff point per day, for example, the final 1.5 hours.
  • Feature-specific themes within Shopify are sensible, so bigger tasks can be worked on in isolation without having an impact on other areas of development that are running concurrently. These should be reflected within git, so that no issues arise when merging multiple tasks into the master codebase.
  • Everything should be sanity checked on a Staging theme before being deployed to the Live published theme for all to see. 

—

Overall, I think this is a really interesting option for Shopify and Shopify Plus merchants, that isn’t as easy to achieve with most other platforms. There are definitely pros and cons, but for a lot of Shopify Plus retailers looking to become more agile and deliver more projects, it’s a really good option. A lot of larger Shopify Plus stores have taken development in-house over time and most that I’ve spoken with are positive about the move and experience.

If you have any questions or additional points, please feel free to add them in the comments below.