Some of you might be wondering what it was like to grow our team of developers from a handful of people to almost a hundred, and all the obstacles that came with it. This is my story. I like to sprint, but this one was more of a marathon.
Pricefx is well known for being brave enough to discover and use a cutting-edge tech stack. But it’s not just the technologies we use that keep the team happy and together.
As the SVP Engineering at Pricefx, I’ve had the chance to see our company’s incredible transformation from a tiny team of Java developers to a robust team of about 90. Now I’d like to show you how our tech stack evolved over the years.
Pricefx began with a simple idea: replace Excel for managing prices with something more flexible and efficient. Our software was designed to cover all aspects of price formation, from analysis and analytics to price setting and calculation. Starting simple, our focus was on small to medium-sized businesses. As our tool became more sophisticated, larger corporations began to recognize its value.
One thing to note is that our software is entirely cloud-based. Initially, we hosted it on a private cloud of rented Linux servers scattered worldwide. As we scaled, we transitioned to the public cloud, Amazon Web Services (AWS) and Google Cloud Platform (GCP). While AWS gave us countless benefits, managing costs was an important concern we had to keep in mind.
As our primary application was written in Java, our initial choice was rooted in the team’s familiarity with Java and its practical, open-source nature. For specific optimization tasks, we also used containerized solutions.
In our early days, we used technologies like MySQL, PostgreSQL, Jetty, Jackson, Hibernate, and Flyway. At one point we decided to avoid the Spring framework in our primary application. This let us dodge many dependencies and keep our options open for other frameworks in the future.
Frontend development posed its own set of challenges. We initially used Google Web Toolkit (GWT), which performed remarkably well for data tables and performance optimizations. Over time, we decided to rewrite the user interface using JavaScript, starting with Ember.js. But we ran into an unexpected hiccup: we ended up writing most of our grid functionality ourselves. On top of that, hiring Ember.js developers was a challenge. So we switched to React, which we still use to this day.
As we started scaling, we expanded our team to include back-end and front-end developers, product designers, and dedicated automation QAs. With this exciting growth came new challenges. Our stand-up meetings became too long, so we reorganized the team around their work domains. This allowed for better domain knowledge and a more streamlined workflow.
Our core application remains a Java monolith, with services built around it. We also have a few microservices, but we’ve found that the main functionality is still best suited to the Java monolith. We don’t have a domain-specific language, but we use an internal API documented and accessible in Groovy.
In terms of database management, we found that in-memory databases aren’t always necessary if servers run at SSD disk speed. We use PostgreSQL for basic analytics, but for clients dealing with hundreds of millions of transactions, we use GreenPlum, a clustered version of PostgreSQL.
Machine learning plays a major role in our operations, primarily in optimization. That said, we found that most of our clients are more concerned with processing challenges and data volume than with AI-driven price suggestions.
Quality assurance is at the heart of our operations. Along with manual QA testing, we invest heavily in automation. We started with a focus on the back-end, using a framework called Spock for writing integration tests. With time, we introduced JavaScript for component and unit tests, and automated end-to-end (E2E) tests using Cypress.js, which outperformed our previous tool, CodeceptJS, in documentation and ease of use. We even dedicated a small team solely to writing and maintaining these E2E tests.
We maintain several test environments that mimic different product versions, including development, upcoming releases, and the current production version. We clone test data into these environments, which lets us test extensively and identify bugs more easily.
We’ve developed an internal analytics module that uses PostgreSQL and supports several types of graphs and data definitions. While we also use Tableau internally, we provide customers with our own internally developed tools. These include a module for data analysis and pricing analytics, allowing data export to customizable dashboards within the system.
Despite our jokingly stated intent to “kill” Excel, we’ve found that some of our customers prefer to pull data via APIs into Tableau or use our Excel integration, sometimes even enhancing them with their own visualizations or additional data sources.
Looking back, we’re so proud of what we’ve achieved. We’ve built a robust engineering team with a healthy culture and released products that genuinely have a positive impact on customers. And we’ve managed to streamline our processes without stifling creativity, which is a huge accomplishment in itself.
Our tech stack evolved in response to our growth and the challenges we faced along the way. But our core objective has always been the same: to democratize pricing and provide an efficient, flexible solution that caters to businesses of all sizes.
Moving forward, we’ll keep exploring new technologies and methodologies, and adjusting as needed to continue offering the best possible product to our customers. We have an exciting journey ahead, and I can’t wait to see where it takes us.
If you want to move forward with us too, take a look at our open roles on our Career pages, or check Glassdoor to see what our colleagues say about their own experience at Pricefx.