State of development at Evermade 2025

We are a creative WordPress agency designing, creating, marketing, optimizing and maintaining websites, web services and ecommerce stores. WordPress is at our core, but we work with other technologies, too. In this post, I will go into detail about how our development team operates.

This is our fifth state of development post. The previous versions are available here: 2017, 2019, 2020 and 2022.  Historically, these posts have been very beneficial for us. Many developer candidates who apply to Evermade have read these before coming to an interview. This blog post also helps us internally. In our dev team, no one knows everything — but everyone needs to understand how our system fits together. And last but not least, I hope this helps someone in the developer community.

In addition to our company values, we as developers also have our own values.

At the time of writing this, we have 70 employees of which half are developers. Our company is split into account teams. Each team has their own clients and all the professionals required to build services: project managers, designers, developers, analysts, and SEO specialists. Our team size is roughly ten people and each team usually has 4-5 developers. We also have the Evermade Care team which takes care of website maintenance and small development.

As a developer, you work in one of these teams. In every team, we have a lead developer who is responsible for running dev operations in that team. This work includes supporting developers across projects, running code reviews, coaching team members, running dev meetings, and so on. In addition, we have senior developers who usually have some extended responsibilities, like taking care of some internal tools or coaching others. Then we also have some other technical leads like a lead UI developer and an AI Lead. As CTO, I’m doing my best to make sure that all these operations run smoothly both internally and externally.

Evermade is a WordPress agency. That being said, we do not blindly believe that a single tool or technology is a solution to all problems, and we constantly explore other solutions as well – but still, 80% of our revenue comes from WordPress projects. We also work with HubSpot CMS and have a dedicated team for HubSpot development.

Surprisingly, many WordPress sites need ecommerce-like features these days. Our go to solution for these is WooCommerce, which we sometimes need to customize heavily. We are also working on Shopify projects – one of them is one of the biggest Shopify stores in Finland.

A small fraction of our revenue also comes from mobile application development. React Native is our go to stack for app development, with WordPress or Firebase as a backend.

Sharing knowledge and inspiring others is a very important part of our competence. We have various channels for sharing and collaborating.

One very important thing is also our #dev-support Slack channel. It’s a channel reserved only for dev issues. Your questions will always be answered on #dev-support. That single channel is one of the most appreciated channels we have!

We also have learning days. That means that you are allowed to use one day in a month for learning or WordPress community work. You can decide the topic as long as it at least somehow relates to our work. Rules for learning days are not very strict, more like general guidelines. You can use an entire day to study a topic of your choice, travel to a conference, or just use an hour here and there – whatever helps you learn best.

Even though we have attracted a lot of recognised, active and respected members of the WordPress community to work at Evermade, we as a company haven’t been that active in it. And we are not alone in this – almost none of the Finnish agencies are active in the community, even if a few of their employees might be. Typically, these involved individuals have been doing community contributions mainly in their spare time. 

As a company, we have always participated in WordCamps in Finland. We have sponsored this event as well as local WordPress Meetup groups a few times. In the last few years, we have also sent a team to WordCamp Europe. This year, there will be eight Evermadeans attending WordCamp in Basel, Switzerland.

As WordPress is one of the cornerstones of our strategy, we wanted to be a better community contributor. First steps towards this have been taken. We have appointed a person to be responsible for community participation, and allowed everyone to use their learning time to make contributions. With our new Five for the Future pledge, we help to ensure that new WordPress versions are translated into Finnish at the time of release, and that event organisers around the world have the help they need.

Although our efforts have only just started and we are looking forward to contributing more, our current efforts have not gone unseen. We were personally invited to attend the State of the Word in Tokyo and have a meeting with WordPress co-creator Matt Mullenweg. The timing of the keynote was unlucky since it was just before the holidays, and we couldn’t justify traveling to the other side of the world this time. In addition to all these efforts, we are closely monitoring and participating in discussions about the future of WordPress and its community at large. 

The majority of our development happens on cloud servers. We are using UpCloud as our infra provider and each developer has their own Ubuntu instance running. The server runs sites with Docker. All build processes are running on that server, not locally.

There are some clear benefits of this approach:

All our developers use VSCode or Cursor for development, which have excellent support for remote file editing. It feels local.

Cloud-based development does, of course, come with some drawbacks:

However, you are not forced to work on a remote instance at Evermade. In some projects, like React-only projects, this doesn’t really make sense.

Our projects run on Dockerized setup. We call this system MAYHEM. It runs NGINX, FastCGI cache, PHP-FPM and MariaDB. It also offers variations for development, staging and production. This makes the whole project extremely portable and we can easily spin it up wherever we want. 

We recently made a major overhaul to MAYHEM and reorganized it. Previously the majority of configurations were saved on the project repository. That made centralized updates difficult. The new version offers a mechanism to run the environment with default configurations and overwrite when necessary. That improves the scalability of our sites.

We have automated some of the most common Docker tasks with our internal CLI tool called “em helper”. It makes it easier to build and spin up projects and do some automation tasks like database pulling.

We have our own base theme and tools which we call Evermade Studio. 

Our goals with this approach are:

The theme is a hybrid theme using PHP templating for example for the header and footer, but blocks for content. We have explored full site editing and it’s definitely an interesting approach for building sites. However, we are building sites for enterprise customers and full site editing doesn’t yet provide benefits in those cases or feel stable enough. We don’t want to (and our clients don’t want to) modify the header or the footer by themselves. The freedom of full site editing is not something our clients are asking – especially at the expense of reliability and stability. 

Theme aims to provide everything to a polished level that lets developers focus on project-specific features and making existing elements unique. Our designers use Figma templates that are synced to the features of our theme ensuring smooth cooperation with design and development. The theme layer is focused solely on presentation. Business logic is separated into its own plugin. 

Our base theme also introduces a concept of modules. Modules are UI components that we don’t want to implement as blocks. Modules bring together related PHP, JS, SCSS and HTML so that everything related to, for example, headers can be developed under one folder. We have found this to be the most efficient way to organize code in large projects and allow a copying functionality between projects. Modules are tools to organize our code, and the scope of a module can be large or small.

Blocks are in a separate plugin. This has made the theme itself very lightweight. It has templates for some fundamental views and a webpack based build process. 

We made the decision not to use ACF to create blocks. We worked with ACF flexible layouts for years, so it would have been easy to just start creating blocks with ACF, especially during the early years of Gutenberg. There would be nothing wrong with that. But on the other hand, there’s no real reason to use ACF either. WordPress has very good documentation for creating blocks with native tools, and the user experience is usually better with native blocks compared to ACF. Instead of rendering form fields with native blocks, users can edit the content on the editor. That improves the content editing user experience by a ton.

The development experience is a bit different with native blocks. Previously with ACF flexible content, we always created a block. It was straightforward. Now, with block editor, you have multiple choices:

Working with the block editor is more flexible than ACF, but it also demands more planning and architectural thinking before diving into code. Through our work with native blocks — especially in projects like GrowthStack and our Evermade Studio Slices feature — we’ve gained a deep understanding of the block editor’s internals. Beyond just adding custom blocks or controls, we know how to programmatically create, modify, and manage blocks to shape the editing experience. 

One of the biggest pushes after the last edition of this series has undoubtedly been the development of GrowthStack. It’s essentially a plugin that brings all the necessary conversion tools to WordPress and integrates those natively to the block editor experience.

Conversion tools like personalization and A/B-testing have become a necessity from the marketers perspective for maximizing the impact of marketing efforts and converting website visitors.

At the same time, we always felt that already available plugins for those needs were not doing that good of a job. Either functionalities were lacking, they were not extensible to our client’s needs, or the user experience was poor and did not integrate to the block editor nicely.

GrowthStack allows us, and more importantly our clients themselves, to create content personalizations and run A/B-test directly from the block editor. The experience is very seamless and feels almost native to WordPress. It also gathers some basic analytics viewable directly from the dashboard and provides AI functionalities to help with content creation.

From a development perspective, GrowthStack has brought lots of new things, mostly related to the product development flow itself. It’s a totally different thing to do development for one project compared to a plugin used by many big websites. Experiences from this have also developed ways of working with internal products like Evermade Studio.

Plugins are the greatest, and at the same time the most horrible part of the WordPress ecosystem. While it’s nice to have a good variety of tools available, it’s also difficult trying to pick out properly made, reliable plugins from the masses.

The general rule of thumb is that we try to avoid installing plugins whenever we can. We pick our tools very carefully. Sometimes, a single hook will do the thing and no plugin is required at all.

There are, however, some useful plugins we install on almost every project:

We host commercial plugins internally in our own SatisPress installation.

For custom functionality, we use a plugin called Evermade Features. Back in the day, we bundled most of the functionality to our theme, but now the idea is to separate functionality to its own plugin.

The plugin does things like:

Most enterprise-level WordPress sites have at least one integration, so these are a key part of many of our projects. We have developed tools for creating and monitoring integrations so that each would be structured in a similar way and developers could start building custom integrations as fast as possible without needing to spend a lot of time setting up various scaffoldings.

Integration boilerplate has base tools for creating integrations that tightly use WordPress core functions and classes for maximal compatibility. The boilerplate is not a functional integration on its own, but it has example code for creating integrations that pull, push, or receive data from other systems. Each integration will be in its own plugin encapsulating code related to an integration within that plugin, making it easier to focus on that aspect of the site.

We want to make integrations in a transparent way. That’s why we’ve created Everwatch, which is a centralized monitoring tool that creates an overview of all statuses of integrations and other functionalities that we want to monitor. We can easily set alarms to emails or to Slack that automatically let us know if there is an issue with an integration and whether it has been resolved. Clients can easily see how their integrations are doing right in the WordPress dashboard.

We mainly use React for three things:

We have made boilerplates for blocks and block frontends which can be extended or modified for your needs. Without going too deep into our React implementations, it’s safe to say that the average developer at Evermade needs at least basic React knowledge.

For mobile applications, we have a React Native base in development. This is not being used in any production applications yet, but we have taken our learnings from previous app projects and are now working to make a solid base for any future native apps. 

WordPress has its own mechanism for interactive user interfaces: Interactivity API. It’s a nice approach for rapidly building dynamic interfaces. However, we prefer React in many cases for a few reasons. React is the industry standard for creating interactive features and is heavily used by the WordPress project and all over the internet. We don’t see much benefit not using React but learning some bespoke WordPress specific custom mechanism for building interfaces. Let’s see how Interactivity API evolve, but currently we are sticking to React wherever possible.

Our primary hosting solution is to run the site on UpCloud’s data center. The infrastructure is created and maintained by us. Essentially, it means a farm of Linux servers, each running docker containers. We have evaluated WordPress as a service platforms,  but decided to run sites on our own. That way, we have full control (and of course, responsibility) to run our sites in the way we want. This also means that we have in-house DevOps knowledge, which is a very valuable asset. Usually, large-scale sites require customized infra, and it’s important for us to be able to deliver.

We monitor our sites’ uptime and server resource usage with Hetrix Tools. In addition to that, we have a custom-made solution to collect diagnostics from sites (like plugin versions). We collect information about the “state of our fleet” to Podio which is a highly customizable platform to organize data.

Typically, when working on websites (mostly non-functional), creating proper end-to-end testing is not something worth doing. However, we have been creating automated end-to-end tests for some websites, especially for ecommerce and lead generation functions. For end-to-end testing, we use Playwright or Cypress.io.

When a site project is finished and the site is launched, it’s moved to our Care team and integrated into our monitoring and automation ecosystem. The team takes care of maintaining the site, keeping WordPress and plugin versions up to date, as well as small-scale further development.

When interviewing developers, having a dedicated team for existing clients and allowing people to focus on projects has been proven to be one of our biggest benefits.

Someone has called our Care team the “backbone of our company”, and it makes sense. Our Care team:

As the number of clients in Care grows, the need for intelligent solutions and automations to cover the day-to-day maintenance requirements of a WordPress site has grown too. That’s why the team places a great emphasis on developing internal tools to make their work more effective.

Care’s custom-built automations (which run daily!) include:

We also have our own Evermade Care plugin, which facilitates communication between clients and the Care team. Clients can send requests directly to our ticketing system, all from the comfort of their own WordPress dashboard.

AI is no longer just a hype — it’s here to stay, and it brings real, tangible benefits to developers. Tools like GitHub Copilot, Cursor, and ChatGPT have quickly become part of the daily workflow, each offering different strengths depending on the task at hand. At Evermade, we actively encourage developers to embrace AI tools and explore how they can boost productivity, improve code quality, and speed up experimentation. On the client side, there’s a growing demand for AI-powered features.

Curiosity is one of Evermade’s values, and we want to encourage our developers to keep learning. One good practical demonstration of these values is our AI-enhanced visual regression testing, which makes sure that websites look as they should after receiving updates. The development was inspired by one developer’s desire to explore how AI could be used in a concrete way in our everyday processes, and now it’s a vital part of our Care automations.

On a more practical level, our developers use Github Copilot, Cursor, and ChatGPT as assistive tools while coding. Note the word assistive. We have defined some ground rules around using artificial intelligence tools, such as:

In addition to us using AI to speed up our work, we have our GrowthStack AI tools for content creation and we’ve created some AI-powered features for customer websites. All these efforts are led by our freshly appointed AI lead.

Security has always been a priority at Evermade, and we continuously work to strengthen it across all fronts — whether that’s through technical implementations, internal processes, or thorough documentation. It’s an ongoing effort, woven into our development practices and team routines.

However, we believe now is the time to take a significant leap forward.

We’ve built the first version of our ISO 27001 –compatible Information Security Management System (ISMS), laying the foundation for a structured and auditable approach to information security. This system brings together risk management, policies, responsibilities, and controls in a single cohesive framework. We aim to achieve the full ISO 27001 certification by the end of 2025. 

We also have some (not necessarily dev-only) tools that we still use daily:

Constant improvement is required in this industry. On the other hand, internal development is time-consuming and we need to keep focusing on the right things. These are currently on our table:

That was it! 

Writing all these is always rewarding because it shows how much we have progressed in the past years. We hope this gave you some ideas or helped if you were considering applying to work with us.

Open positions Contact us