Case Study – Elastic Path

Elastic Path is a B2B software company offering their e-commerce platform as both a SaaS and on-premise solution for building and managing sophisticated online stores.

This is a story about the first 5 years of Elastic Path from launch to $6M in annual revenue by one of its co-founders, Dave Koo, who is now one of our Principal Software Engineers here at Steel Toad. It’s a little long-ish so grab a coffee, dig in and enjoy!

Prior to the launch of the Elastic Path product, 2 small web development agencies had merged. One of those agencies was run by me where I had developed our own e-commerce platform, written primarily in Java over the course of a few client projects, but at the time it was only used for our own agency clients and had not been launched as a standalone product.

(NOTE: This story mostly mentions Java technologies. Our backend work is now generally based around both the Node.js and Java ecosystems.)

Our newly-merged agency (still small, only 6 people) really wanted to make the jump from being a services company to a product company, so we started looking for ways to do that and felt like our e-commerce platform was our best shot at the big leagues.

At the time, Java e-commerce platforms were generally only available to large enterprise companies due to their high price point (starting at around $50K).

Since our platform was still missing a lot of features compared to those enterprise products, we figured we could position that as an advantage and decided to launch our product as “The #1 Mid-Market Java E-Commerce Platform”. Which was a bit of a stretch but technically true….since we were the only mid-market java e-commerce platform 😎

We priced the product at $5K for a perpetual 1-CPU license (this was before SaaS was a thing in B2B software), created some sexy-looking marketing materials and launched an SEO/PPC campaign.

At the time, a lot of new open source Java frameworks were just coming onto the scene (Spring, Hibernate, etc). While our enterprise e-commerce competitors had all built their products on older proprietary Java technology, we made a bet on “open source Java” as the future.

We knew we couldn’t compete on features yet, but we felt that by offering a significantly lower cost product built on newer/better technologies and marketing it to developers who wanted to use those newer technologies, we might have a chance.

So we focussed our messaging around developers with things like our “Flexibility-First Framework” and describing Elastic Path as a “developer-friendly” product.

I was in Hawaii at the time with our CEO – we had been invited to pitch Hawaiian Airlines on some custom web development and figured even if we lost the pitch (which we did), heck we’d at least get a little vacation out of it – when the first leads started coming in from our search engine campaign. Most of them were companies we’re never heard of but 2 caught our eye: Xerox and Proctor & Gamble. They were both Fortune 500 companies.

The problem was, we thought the guys back in the office were playing a joke on us submitting fake leads, so we didn’t even bother responding to them for a couple days lol. When we finally found out they were legit, we still couldn’t believe it.

I mean come on….Fortune 500 companies reaching out to….us?!? Within 1 week of launching a search campaign! We were 6 people in a small office in Vancouver, Canada. This was the stuff dreams were made of. Anyway, we jumped on calls with them not really knowing what to expect.

More leads started coming in (we were averaging about 10 inbound leads a day just by targeting “java ecommerce software” on Google), and we quickly realized we were onto something. It turns out that the e-commerce decision maker at medium-to-large companies (typically VP Marketing) was often asking their engineering team to make a shortlist of e-commerce platforms that they recommended. Those engineers would Google “java ecommerce software” and find us in the first 3 results. Meanwhile, our competitors were all targeting the VP of Marketing with their messaging (hence focussing on features, not technology). So by focussing on the developer experience, we’d stumbled on a bit of a blue ocean and were getting on a lot of those shortlists.

We soon closed the Proctor & Gamble deal. And then the Xerox deal. I started working on a product architecture roadmap to plan (aka. figure out) how to integrate more of these new open source Java technologies into our tech stack, rather than reinventing the wheel.

Since we were so early, we sometimes ended up picking technologies that fizzled out in terms of market adoption and so we ended up replacing them later with more popular choices that were easier for us to “sell” to developers.

It was fair to say that the amount of technology evaluation, prototyping, selection and integration we were doing in those early years was substantial.

Around the same time we started hiring more engineers to work on building out our product roadmap. I took on the role of Team Lead. I would evaluate and prototype technologies, create a reference architecture for how to integrate them into our product, build 1 or 2 sample features (what we call Reference Feature Implementation) then work with my team to implement features in subsequent sprints. We were moving fast so it was a challenge for me to stay just enough ahead of the team that they weren’t blocked.

We were one of the early adopters of Hibernate, the popular open source Java ORM. Since we had quite a complex database model (over 100 tables with lots of joins) and needed to support all of the popular RDBMS products (PostgreSQL, MySQL, Oracle, SQL Server), and our target customer was Java developers (not DBAs), using Hibernate was a key decision that allowed us to not only develop our product faster but also win more deals.

Different customers would have preferences in terms of 3rd party integrations so we spent quite a bit of time integrating with all of the most popular providers for things like shipping, payment, taxes, etc.

With a large product catalog, search was essential, so we implemented Lucene/Solr to provide fast full-text faceted search/browse across the entire catalog.

We employed various caching strategies such as Java object caching with Ehcache for our product catalog with cache warming/preloading as well as Hibernate L2 caching.

As the product evolved, more and more merchandising features were added including a product recommendation engine with features like cross-sells, up-sells, recommended accessories, bestsellers, customers who bought X also bought Y….basically all the stuff you see on an Amazon product page.

One feature that was particularly popular was our Promotions Manager that allowed store admins to visually create sophisticated promotions from a collection of promotion rule elements (eligibilities, conditions and actions) which the store developers could extend with their own custom rule elements if needed. The promotions could contain nested rules with boolean AND/OR elements allowing promotions like: IF the shopper created an account in the last 7 days AND the shopper has more than $100 of items in their cart (excluding the following ineligible products…) THEN give the shopper 20% off any item in category XYZ. Behind the scenes, we would translate these rules into a DSL that could be read by the Drools rules engine and fire them through the engine as needed. 

For the first couple years, I was pulled into hundreds of sales calls and product demos since we didn’t have any sales engineers yet and we found that engineers liked talking to the guy who was in charge of the product, so our close rate was pretty good with me and our head of sales on the calls.

This turned out to be good from a product management perspective since it meant that I was very close to the customer, could see exactly how they reacted to things on sales calls and basically knew exactly what they wanted and how much of a pain point it would solve. I would go into the product backlog after each call and update it to add “votes” for features, noting which prospect requested the feature and on which date. This data was then used as a data point to help guide prioritization of new feature development.

I had very little software sales experience (or any sales experience for that matter) so it was a pretty steep learning curve at first.

One thing we learned was that, even in the enterprise software space, you don’t need a ton of big brands or social proof to close deals in the early days if you have a good product. But it does really help to have 3 or 4. On sales calls, people would ask us “so who are some of your key clients”, and at the start we would hate that question because we didn’t have a good answer. But after getting a few brands on our platform that everyone knew, things changed dramatically. When asked that same question, we would confidently name those brands, the company would be like “oh wow, those are great brands” and then we’d move on to the next topic. They never asked for more than a few. You just need to get those first few for it to get easier.

One common objection we heard on calls was “But you’re missing feature X!”. Again, this was hard at the start until we started saying “That’s true, but with the money you save by going with us, you can spend some of that budget adding any extra features you need that we don’t have out of the box.” That seemed to make sense to the companies we were talking to and took a lot of pressure off of us.

Another common objection that came up was “You guys are a tiny shop, what happens if you shut down and your product disappears?”. We used to say “well we could do a source code escrow thing in that case where you would get the source code if we ever closed down the business”. That kind of helped but still didn’t feel great. Then one day I just threw it out there on a sales call to see what would happen – “what if we just gave you the source code as soon as you bought the product?” The guys on other end of the phone went silent. No enterprise software vendor had ever done that, to our knowledge. They said “well if we had the source code right now, we wouldn’t need to be having this conversation”. And so I said “great, we’ll sell you a source code license for twice the price – $10,000 per CPU. Then you can customize it to your hearts’ content”. And they went for it on the spot :).

And from that point onwards we started selling source code licenses. This turned out to be a major factor in our growth – it allowed us to, overnight, double our pricing AND eliminate a major sales objection, all in one shot. (Although upgrading them to a new version after they had customized the #$%@ out of their current version was another story.)

Yep, it was a risky idea since our source code could potentially leak out to the public but we again made a bet: (1) the companies that could afford our software were big enough that they would never risk using it illegally and (2) the companies that couldn’t afford us never would have been customers anyway. In reality, we never once heard of or discovered our source code out in the wild without a license.

Shortly after we started closing deals we found that companies were coming back to us for help with implementation. Even though they had their own developers and access to our source code, they would often need complex customizations to the product and they felt safer having us do this for them. So we created a Professional Services group.

One of our other Elastic Path co-founders, Justin Tilson (also a Principal Software Engineer and Founder here at Steel Toad), had been the lead engineer on many of our client projects up to that point so we enlisted him to now lead that customization work for our e-commerce clients.

Justin spent many years leading these Elastic Path client projects and got experience extending and integrating the Elastic Path platform with many different 3rd-party solutions. In some cases, these customizations and integrations would get rolled back into the core product and be available to all customers in future releases.

Justin’s more notable client projects involved integrating document management with Elastic Path’s e-commerce engine for Xerox, as well as building a large, multi-domain, multi-language, multi-currency e-commerce site for Clearly, a large e-commerce eyewear brand that operates in many different countries. A few years after rebuilding their online store on the Elastic Path platform, Clearly was acquired by Essilor (the world’s largest manufacturer of prescription eyewear lenses) for over $300M USD.

In some years, these services projects ended up generating more revenue for us than our software licensing sales and they also helped us fund and accelerate our product engineering efforts. So it’s hard to overestimate the important of the Services team to Elastic Path’s success.

As we started working with more major brands like Google, Virgin Mobile, Time Magazine and Avis, it meant that our platform needed to perform well. So I spent a good chunk of time overseeing performance testing, diagnosing bottlenecks and tuning across all layers of the tech stack.

These brands would often ask us on sales calls to describe our highest volume customer deployment. They wanted to make sure we could handle the amount of load they were going to send to their new online store. This, of course, created a problem in the early days when we didn’t have any large deployments.

So I decided to solve this dilemma by building a massive test store that we could use to prove that our system could handle any reasonable load that even a Fortune 500 e-commerce brand might need.

To do this we put together a tiny performance engineering team who created automated scripts to build and manage a large e-commerce store with 1 million products (including multiple SKU variations of each), millions of orders, millions of customers, etc. In total, over 100 million rows spread across all the tables in our DB.

Once the database was built, we set performance requirements for various situations (no load, average load, high load, etc) for each user scenario in both of our apps (online storefront and back office admin). We then used various load testing tools to hammer the apps with very realistic usage scenarios.

Not surprisingly, we found many performance issues! So we fixed the major ones, prioritized the rest in the backlog, benchmarked final performance against our test store and then authored an Elastic Path Performance White Paper that detailed our performance and scalability testing and results.

Handing this white paper to prospects was usually enough to put any of their fears at ease. Sure it wasn’t a real production client site, but we had clearly proven we could scale and that was good enough for them. As we released new versions of our Elastic Path product, we would update the performance test automation scripts and migrate our large test site and DB to the latest version so that we could guarantee high performance on each new release.

About a year after launching our product, we started scaling up our product engineering team. At first the growth was slow, we only added a few engineers in the 2nd year. We were still bootstrapped so we could only grow as fast as our revenues would let us.

Then things started to pick up as sales grew and we found ourselves with more cash to reinvest back into the product. The 3rd year we grew the product team from 7 to 15 people. The 4th year we ramped up even faster.

By the end of the 4th year, the company had 70 staff and 45 of them were in my product engineering group. By that time we had the resources and the cash to go really aggressive on our roadmap and knock off a bunch of features as well as make some significant improvements to our product architecture. As you can imagine, those 3rd and 4th years involved me doing a lot of interviewing! I hired 40 people in-house (software engineers and QA engineers) and also brought in offshore teams from Eastern Europe and Brazil. We had some amazing engineers who were also just really great people to work with and without them I can confidently say that things would not have turned out nearly as well as they did for us.

That 4th year we had 7 product teams in total so we had to make various changes to how we operated such as doing individual team scrums at 9am and then having a “scrum of scrums” at 9:15 with all the team leads, our 2 project managers and myself, to get updates and address any urgent blockers before we got too far into the day.

We had a weekly resourcing meeting that sometimes felt like a combination of “tug of war” and playing Tetris with humans. When the Services team landed a new client project, I often had to try and defend my Product engineers from getting poached because I knew the Services project managers would be keen to grab them for their own projects rather than have to delay their projects until other Services engineers were freed up. Having said that, I also had a bad habit of trying to do my own poaching to grab some of the best engineers from the Services team to come work on the core product 😇.

Over time, as we added more features and value to our product over the years, we gradually raised our prices until they were roughly on par with the other enterprise e-commerce offerings in the market. By that point we were regularly competing on deals with the e-commerce software companies that we had looked up to and admired only a few years earlier.

Once we got to our 5th year, probably half the deals in our pipeline were with billion dollar companies and we were closing deals with a roughly $200K average deal size every week or two (our biggest deal that year was $3M). By then we had worked with over 180 customers including many recognizable brands: 24 Hour Fitness, Air Canada / Aeroplan, Avis Rent-A-Car, Breville, Garmin, Google, Proctor & Gamble, Scott Sports, Sunoco, St. Jude Children’s Research Hospital, Symantec, Telus / Koodo, Time Magazine, Vancouver 2010 Winter Olympics, Virgin Mobile, Xerox.

We had also managed to land some great industry recognition: “Visionary” in the Gartner Magic Quadrant for Digital Commerce, “Contender” in the ForresterWave for B2B / B2C Commerce, and #23 Fastest Growing Company in Canada in the PROFIT 100 list.

Justin and I eventually left the company to pursue other opportunities. My mental health was also suffering after being on what felt like a wild roller coaster ride for 5 years, so I took a few months off after leaving to just decompress and get back to a good place.

Since that time, Elastic Path has continued to grow. Their annual revenues are now well into the 8-figures, they’ve raised a total of over $100M in VC funding and have acquired 2 other startups, including one backed by Y Combinator.

All in all, looking back on it, those 5 years took me on an amazing journey that I’m super grateful for having experienced. Startups are tough but they’re also a ton of fun (and rather addictive once you get hooked), so I’m looking forward to helping more startups build outstanding software products and bring their vision and dreams to life.