Buying third-party software rarely goes exactly as planned. Most of us aren’t trained for it, I certainly never took a class in college on how-to buy software, yet many of us may find ourselves involved in a software purchase. This is a story from 2014 about integrating enterprise software while I was at Wayfair, taking you through the journey of procurement, MVP, expansion, and long-term support.
What do Wayfair Transportation engineers do? What are these integrations you need?
So Wayfair is a website that sells furniture right? What’s so hard about that?
They sell furniture yes, but let me ask you a quick question, when was the last time UPS dropped a brand new vanity off on your front door? …Probably never. The truth is, shipping what’s called “large parcel” goods across a large geography like the United States is incredibly complicated.
One complicated component of shipping large goods is in the “home delivery” segment of the journey. If you’ve ever bought large furniture, you probably either A) rented your own truck, grabbed some friends, and slowly struggled to get it into your home or B) you had a company deliver it for you and they probably had to bring it into your home and put it in a room and maybe even help assemble it. If it was option B you also probably had to schedule a date and time window of when that delivery would be made and you had to be home. Maybe they were late and you missed them or they broke your lamp installing the furniture and told you tough luck. When you think about all that goes into delivering furniture: reservation dates, route planning accounting for time to bring things into people’s homes, managing the fleet of delivery trucks, customer experience, you find yourself with a very complex problem space.
In the past Wayfair outsourced this problem to partners who ran the last-mile delivery operations for us, but the problem was they weren’t very good at it. Customer satisfaction was low, there was almost no visibility into how efficient the route planning was (it wasn’t) and so they spent more money than necessary, and had no ability to schedule deliveries in advance (couldn’t ensure these delivery partners could fulfill on customer promises). It was clear that the right business decision was to bring these operations in-house. That decision was made and so the task of supporting it was brought to my team in engineering. The problem: managing all of these operations requires fairly sophisticated software, AND…Wayfair had already signed the lease on its first building.
The Build vs. Buy Conundrum
Wayfair has a large, incredibly talented team of engineers, in fact technology is a competitive advantage for the company. Sometimes though, what we want to do is incredibly ambitious, and we gain a huge advantage by getting it out the door quickly. As we looked over the laundry list of features that needed to exist to make this delivery operation work (optimal route planning/fleet management/delivery reservations) we realized that it would be a monumental effort to build this all ourselves. Our unfamiliar team would need months if not years to build it all to scale. So we figured out which parts made sense to build ourselves and for the rest, somewhat reluctantly, looked to the software market for help.
What do we need?
After our product managers did some research, we ended up looking at four vendors. Two of them were eliminated right away after a couple intro calls, as we realized they didn’t fulfill all of our cases. So, we had driven down to two finalists:
Descartes Systems Group: The big guy, one of the leaders in the space with a mature product and several large, well known clients. Very enterprisey, ugly-looking software but seemed to do the job. More expensive. Less leverage in negotiations
DispatchTrack: A small start-up in the space. New flashy UI/UX, but not as tried and true. Cheaper, looking for their first big client and highly willing to negotiate.
This was my first integration project as a tech-lead. Suddenly I had to evaluate these vendors and help choose the right one. I was nervous. I spent the days leading up to these demos researching “questions to ask when buying software”:
- What APIs exist
- How do I use them (SOAP, REST, FTP)
- What does their documentation cover
- API response time
- Cloud or on-prem
- How many concurrent connections can it handle
- What environments exist (dev/sandbox/QA)
- What redundancy exists in their platform
- Have they tested failover procedures regularly
- How often is the system patched
- How long does it go down for during updates
Descartes was kind enough to give us a 300-page pdf, documenting all of their APIs, for my enjoyment. I printed it out and read through the whole thing so I had a good starting place with them. I was determined not to miss anything. Of course, hindsight… I would’ve asked some other questions, not just of the vendors, but of ourselves:
- What can we and what can we not configure in the system? What will we need to configure?
- Can we access the database directly? Will we need to?
- Can you do a demo of a high-load? How much volume will we need to pump through this?
We started evaluating. Having several day-long presentations is rough, there’s so much material to cover and of course we don’t want to miss anything. Meanwhile the sales folks from these vendors want to make sure we see all of the “cool stuff” their products can do, eschewing conversation on some of the important topics like security and resiliency. We had to be sure we got all of the information we needed for making a decision.
How much does it cost?
There are two big categories of cost in buying software. The obvious, visible cost of the software itself, and the hidden cost of your own teams integrating it, which also drives the time-to-market. There’s a common misconception that when you buy software, you just “plug it into your system” and everything’s good to go. I wish it were that easy. The cost of buying a harder-to-integrate piece of software is engineering’s responsibility to surface.
When it came to this delivery product, we already had a ton of custom software Wayfair had built over the years. Integrating a new product into all of these existing complex systems and workflows would be no easy task. When evaluating the cost of integration, we had to be thorough:
- What documentation is available and how robust is it?
- What is the breadth of available APIs?
- What communication methods can we use?
- How much implementation support will the vendor provide?
- What environments are available to develop in?
The list goes on, but these all ultimately determine how easy a vendor is to work with.
From the answers we got, we had a strong sense that we would be forced to code our way around DispatchTrack’s system in order to get our desired behavior. Despite DispatchTrack being significantly cheaper, we estimated that we could get an MVP out into the wild 2-3 months quicker with Descartes, and the cost of delay drastically outweighed the initial software savings. We successfully made this case and went with Descartes!
So we’ve bought some software
The hard part is over, we’ve gone through the grueling evaluation and decision-making process and finally have our shiny new software. Job well done. Now, it’s time to figure out how to integrate the product. The first rule, how do we make contact with reality as quickly as possible!
Thanks for reading! Part two will be all about building an “MVP” and how we managed business’ expectations.