Scaling Pricefx engineering | Life at Pricefx

Written by Pricefx People & Culture | Jul 23, 2026, 12:13:20 PM
 

Every software company that wants to excel in its market and earn a real share of it needs to scale up at some point, and it also needs to shape its engineering culture. If you’re curious about how we coped with that change, this is the right five-minute read for you.

As a leading provider of price optimization software, Pricefx is inevitably growing, and with that, our culture and priorities need to be reshaped a little.

Having already been through the process of scaling Pricefx, I’ve gained invaluable experience that shaped the engineering culture we enjoy now. It’s difficult to list every lesson we’ve learned, since we’re still growing and improving, but here are the top eight that have stood out to me the most. Maybe you’ve learned a few of these yourself.

8 lessons from scaling Pricefx engineering

1. Embrace learning and growth

On our expansion journey, we quickly realized how valuable it is for our software engineers to be adaptable. We weren’t searching for experts focused mostly on a single framework. Instead, we were on the lookout for people who had a hunger for knowledge and the ability to grow.

For example, when we need Java proficiency on a project, we don’t mind hiring a C# developer with an excellent reputation. When we did exactly that, the developer quickly became an essential member of our Java team. Gradually, several of our Java engineers moved into JavaScript. And as Pricefx grew, our needs evolved. We started with Ember and shifted to React, where we found many more candidates. So why focus on doing the same thing, when encouraging growth helps everyone win?


2. Find the ‘sweet spot’

In our experience, every engineer has their own ‘sweet spot’ where they feel most productive and satisfied. Some people excel at defining the framework, shaping concepts, and adopting new technologies, even if they’re not especially enthusiastic about business features. Others are more maintainers than innovators. They get satisfaction from enhancing, tuning, and fixing existing parts of our applications, preferring stability over constant change.

Then we have our innovators. These are the people who are energized by creating something new, innovating for a while before needing to move on to a fresh challenge to stay motivated. Recognizing and nurturing these individual strengths has been a major part of our culture.

3. People over technology

At the end of the day, software development leadership is really about people. When you work with people, you need to balance human factors like managing interpersonal issues, team tensions, egos, and personal problems. Technology is only one piece of the puzzle. Our success really comes from understanding and addressing these human complexities.

4. Cultivate psychological safety

We highly value psychological safety on our team. When things don’t turn out as expected, which we all experience at one point or another, we focus on intentions rather than blame. For instance, a regression bug following a low-level refactoring meant to improve performance is a setback on a project. But for us, it’s important not to discourage the engineer who took on the task. Instead, we help them fix the issue and learn from the experience so they can avoid similar mistakes in the future.

5. Leadership influence

We embrace the idea that a manager’s output equals the output of their organization, plus the output of the neighboring organizations under their influence. In our culture, leadership is about empowering others and enabling collective success.

6. Avoid the cargo cult

We actively discourage the ‘cargo cult’ mentality, the belief that following certain processes or ceremonies without understanding their purpose will magically solve problems. Instead, we emphasize understanding the why behind our processes, to foster a culture of intentionality and purpose.

7. Adapt team structure as you scale

As more and more people joined our team, we noticed that stand-ups were taking longer, communication was getting harder, and engagement was shrinking. To fix these growing pains, we drew inspiration from Spotify’s agile structure. We introduced sub-teams with specialized roles, each with a unique Pricefx name like Chilli, Tabasco, Pepper, Vanilla, and Mustard. This structure made our communication much smoother, and we can see our people feeling more engaged.

8. Redefine and contextualize metrics

Another important lesson is that traditional metrics like lines of code (LOC), number of merge requests (MRs), and bugs closed don’t show the complete picture of productivity. We’ve found we understand productivity better when we put more value on business outcomes like:

  • active users
  • user engagement
  • time taken to adopt new features
  • time to onboard a new customer for a released feature.
  • test coverage
  • build pipeline durations
  • average peer code review duration
  • number of regression bugs per time period
  • number of reopens per ticket
  • resolution time for critical tickets
  • ratio of externally vs internally reported bugs.

These metrics align better with our business goals and give us a more holistic view of our productivity. We also recognize the value of supporting metrics when they’re used in the right context. These are things like:

As you can see, the journey of scaling Pricefx has taught us quite a bit. We now know that successful growth is about more than technology. It’s about people, adaptability, and constant learning. And we’re looking forward to the next chapter of our scaling journey. We can’t wait to share it with you, so take a look around for more reading here at our Learning Center.